RFC 3669

Guidelines for Working Groups on Intellectual Property Issues

📅 published February 2004, from ietf

Guidelines for Working Groups on Intellectual Property Issues 🎀

Okay bestie, so this is RFC 3669 ✨, titled Guidelines for Working Groups on Intellectual Property Issues. It came from the Network Working Group, written by S. Brim of Cisco Systems, Inc., and it's dated February 2004. It's categorized as Informational 💅, and it Updates: 2026 🦋. Nothing here is a standard, just a very helpful guide.

Status of this Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 🌸

This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF.

Table of Contents 💜

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  The Problem  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  The Approach . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . .  4
       4.1.  PPP CCP and ECP. . . . . . . . . . . . . . . . . . . . .  4
       4.2.  IPS WG (IP Storage). . . . . . . . . . . . . . . . . . .  5
       4.3.  PEM and PKI issues . . . . . . . . . . . . . . . . . . .  5
       4.4.  VRRP (Virtual Router Redundancy Protocol). . . . . . . .  6
       4.5.  Secure Shell (SecSH) . . . . . . . . . . . . . . . . . .  6
       4.6.  IDN (Internationalized Domain Name). . . . . . . . . . .  7
   5.  General Principles . . . . . . . . . . . . . . . . . . . . . .  8
       5.1.  Types of IPR . . . . . . . . . . . . . . . . . . . . . .  8
       5.2.  When to Think About IPR. . . . . . . . . . . . . . . . .  9
       5.3.  IPR as a Technology Evaluation Factor. . . . . . . . . .  9
       5.4.  Patents versus Pending Patents Applied For . . . . . . . 10
       5.5.  Applicability: It's Hard to Prove a Negative . . . . . . 11
       5.6.  Licensing Terms. . . . . . . . . . . . . . . . . . . . . 12
       5.7.  Third-Party Disclosure of IPR Claims . . . . . . . . . . 14
             5.7.1 Third-Party Disclosure Advice. . . . . . . . . . . 14
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
       8.1.  Normative References . . . . . . . . . . . . . . . . . . 15
       8.2.  Informative References . . . . . . . . . . . . . . . . . 16
   9.  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17

1. Introduction 🧚

Okay so this memo gives working groups a conceptual framework and some rules of thumb to help them deal with IPR issues. The goal is to find a balance between the needs of IPR claimants and the implementers of IETF standards that fits the current times 💖. As part of distilling principles for handling IPR in IETF working groups, it also includes case studies of how working groups have treated IPR. In other words, it documents the running code of the IETF process 🔥.

This memo does not describe IPR procedures for document authors or IPR claimants. Those are covered in two other memos, on submission rights [5] and IPR in the IETF [6]. Instead, this one is for working groups that are trying to decide what to do about technology contributions that come with associated IPR claims 💅.

2. The Problem 🌈

Traditionally the IETF has tried to avoid technologies that were "protected" through IPR claims. But compromises have been made since before the IETF was born 🙈. The "common knowledge" of the IETF, that IPR-impacted technology was anathema, has never admitted that the Internet has run on IPR-impacted technologies from the very beginning. Nowadays the majority of the useful technologies brought to the IETF have some sort of IPR claim attached to them, so it's a whole vibe 💀.

It will always be better for the Internet to develop standards based on technology that can be used without concern about selective or costly licensing. However, increasingly, choosing a technology that is not impacted by IPR over an alternative that is may produce a weaker Internet 😭. Sometimes there simply isn't any technology in an area that is not IPR-impacted. It is not always the wrong decision to select IPR-impacted technology, as long as the choice is made knowingly, after considering the alternatives and taking the IPR issues into account ✨.

The IETF is not a membership organization. Other standards-making bodies may have membership agreements that member organizations must sign and adhere to in order to participate. Membership agreements may include strict procedures for dealing with IPR, or perhaps a requirement that technology must be licensed royalty-free. This is currently not possible in the IETF 🥲.

Even if the IETF had membership agreements, they would be difficult to write in a way that covered IPR issues, because the IETF's work includes technology from other sources and because the IETF collaborates with organizations that take different approaches to intellectual property 🫶. The IETF can run into four different IPR situations at almost any time during the life of a document:

  • A document submitter notes their (or their represented organization's) IPR claim regarding the contents of the document.
  • A non-submitter IETF participant claims that the contents of a document are covered by their (or their represented organization's) own IPR.
  • An IETF participant notes IPR that is claimed by an individual or organization with which neither an author of the document, nor the participant noting the IPR, have an affiliation.
  • An individual or organization that does not participate in the IETF, but that monitors its activities, discovers that a document intersects that individual's or organization's established or pending intellectual property claims. It may come forward right away, or wait and let the IETF work progress 👀.

In working group activities, the IETF does not have detailed rules for each situation. Working groups essentially have only one rule they can invoke, about individuals not participating in activities related to a technology if they do not disclose known IPR. Beyond that, a working group can only make recommendations and requests 🍓.

Since every case is unique, and there are close to no general rules, working groups need a great deal of freedom in dealing with IPR issues. However, some amount of consistency is important so that both contributors and users of eventual standards can know what to expect 💜.

3. The Approach 🦋

The goal of this memo is not to make rules. The goal is to give working groups as much information as possible to make informed decisions, and then step out of the way 🙌. The other IPR working group memos [5][6] lay out what needs to be done once a particular piece of technology is selected as a working group draft. However, that doesn't help when a working group is trying to decide whether or not to select a technology in the first place. This third memo is written to help with that decision. We want to build a conceptual framework, a new set of "common knowledge", to make it easier for working groups to deal with intellectual property issues 🎀.

To do so, we first present "case studies" in Section 4: real events that have happened in recent years, how different working groups dealt with them, plus notes on possible lessons to be learned 📚. In Section 5, we expand on these lessons and try to extract general principles ✨.

4. Case Studies 👑

The best way to know what works in dealing with IPR is to look at past attempts to do so. The following are selected as cases from which general lessons might be extracted. Other lessons might come from other cases, but the cases below cover the important ones 💅.

4.1. PPP CCP and ECP 💖

The PPP Working Group adopted technology for PPP's Connection Control Protocol and Encryption Control Protocol even though an IPR disclosure had been received for it. They told the IESG that they believed the patented technology was the best approach, and that it was better than no standards at all 🫶.

At that time, under the policies documented in RFC 1602 [1] (the precursor to RFC 2026), progress on any standard was supposed to stop at the Proposed Standard phase until specific assurances about licensing terms could be obtained from all IPR claimants. However, as described in RFC 1915 [3], in the case of PPP ECP and CCP, the IPR claimant balked at the requirement for specific assurances 😤.

In the end, with support from the working group, the variance procedure described in RFC 1871 [2] was followed to grant an exception to the RFC 1602 requirements. If it had not been granted, the ECP and CCP standards could have been blocked permanently 😱.

Lessons:

  • IPR claimants, even when their intentions are good, may strongly resist being forced to make specific public statements about licensing terms. If explicit statements of licensing terms are required, then the publicly stated terms will probably be "worst-case", which would provide little useful information 🙃.

4.2. IPS WG (IP Storage) 🌸

The IPS (IP Storage) Working Group evaluated technology developed outside of the working group: "secure remote password" (SRP, RFC 2945 [7]). At the time, there was one known IPR claim, and the proposed licensing terms were apparently reasonable. SRP had become a proposed standard without going through any working group, so IETF participants may have been less likely to notice it in order to make statements about IPR. In any case, two more possible IPR claims were uncovered after the IPS working group had already decided to make SRP required 😳. One of the possible IPR claimants did not make a strong IPR claim itself, and did not want to take the time to determine whether it actually had a claim, though it acknowledged it might have one. In both cases it was difficult to obtain concrete information on possible licensing terms, even though words like "reasonable" and "non-discriminatory" were used in the IPR statements. Rumors of what they might be like did not sound good 💀. The working group participants took the claims, potential and otherwise, very seriously, and decided not to use SRP after all, even though they had already chosen it based on other criteria 🥹.

Lessons:

  • IPR claims may appear at any time in the standards process.
  • Take impreciseness seriously. Attempt to get clarification on both IPR claims and licensing terms 🔍.
Part 2 is coming, bestie, and it picks up with 4.3 🦋✨

4.3. PEM and PKI issues

Okay so the PEM (Privacy-Enhanced Mail) Working Group wanted to use public key technology 🔐✨. In the mid-90s, the basic principles of public key infrastructure had already been patented for years 💀. The patent holder had a pattern of actively enforcing its rights and preferred software sales over licensing 🙈. The group saw this as a significant potential issue, one that could possibly get in the way of the easy deployment of Internet technology. But here's the tea: there was no alternative technology that came close to its capabilities. Swapping it out would have hurt the standard's usefulness even more than using a technology with IPR claims 😭. The case was so compelling that participants decided to move forward on standardizing it and even requiring it 🫶.

One thing that got noted was that the patents were mature and would expire within a few years 🦋. So even though they might be a big deal at first, in the long run they wouldn't be. That lowered the perceived risk of using the IPR-impacted technology 🌈.

Lessons:

  • IPR is just one issue in deciding whether to adopt a technology.
  • IPR is not an all-or-nothing issue. There are different types and levels of IPR protection.
  • The IPR's lifecycle phase can be a consideration.

4.4. VRRP (Virtual Router Redundancy Protocol)

The working group was standardizing VRRP based on a protocol that was developed outside the IETF 🧚. The IPR claimant backed that protocol and said it would license its IPR for that protocol if it became the standard, but not for the similar protocol the working group was building. The participants decided to go ahead and standardize the protocol developed in the working group anyway. The IPR claimant has only claimed its patent when someone else claimed a patent against it 👀. There's no evidence that participants actually thought about the implications of the IPR claim when they went ahead with their choice of protocol 💅.

Lessons:

  • IPR claims should never be disregarded without good cause. Due diligence should be done to understand the consequences of each claim.

4.5. Secure Shell (SecSH)

This is mainly an unfinished trademark issue, not a patent issue, since the patent issue has been worked out outside of the IETF ✨. The holder of a trademark wants the IETF to stop using "SSH" in the names and bodies of its proposed standards. The working group participants went through the details of the claims, plus the possible implications and risks, and decided to keep using the names as they are now 🔥.

Lessons:

  • Working group participants can evaluate IPR claims not only for their possible validity, but also for the risk of misjudging that validity. The impact of honoring the IPR claim may be major or minor.

4.6. IDN (Internationalized Domain Name)

The IDN Working Group dealt with a bunch of IPR claims 🌸. Several didn't overlap with the technology at all. The claimants said the patents were being announced just in case the working group decided to go that way. In one case, even though a patent was announced as purely defensive, lots of participants investigated the claims themselves, and they concluded it did not overlap.

In one case, an IPR claimant asserted that the working group's documents, and in fact the IETF as a whole, were infringing on its rights 😳. Individual participants consulted their legal advisers, concluded the claims would not overlap the working group's developing technology, and decided they need not be concerned. That was reflected in the direction the group as a whole decided to take.

In another case, patent claims were asserted that appeared to be derived from working group discussion, rather than the other way around (or independent discovery). The claimants were known to be following the working group's work when the ideas were proposed, and their patent filing came considerably later 🕵️.

In 2000 the IDN Working Group discovered a patent that some participants thought might apply to one of their main drafts. If it did, it could affect their work profoundly. To the extent that some suggested that if they couldn't work out reasonable licensing terms with the IPR claimant, they might just disband 😱. As a group and individually, participants corresponded with the IPR claimant to get an explicit statement of licensing terms, preferably royalty-free. By doing so they gained a better understanding of exactly which working group activities were seen as infringing on the patent, and at least some understanding of the IPR claimant's intentions and philosophy. Since the patent holder seemed to have an interest in using the patent for profit, the group discussed the issues on its mailing list. They openly talked about how they could change their proposed technology to avoid having to contest the patent, and about the extent to which the patent might be countered by claims of prior art. Meanwhile, individually, they were talking to their legal advisors. Gradually, a collective opinion formed that the working group documents did not infringe on the patent. Since then, the patent has been ignored. However, they are keeping a watchful eye out for continuation patents which might have already been submitted 👀.

Lessons:

  • It's sometimes beneficial to push IPR claimants to find out what they think their claims cover and what their licensing terms are.
  • Possibilities of prior art should be considered.
  • It's all right, and sometimes beneficial, to discuss IPR claims and gather information about possible prior art on the group list. The results of such discussion can be considered when deciding whether to develop a technology (but remember that neither the IETF nor any working group takes a stand on such claims as a body, and the group is not the best place to get legal advice).

5. General Principles

Given the case studies above, there are a few principles that working groups can start with in dealing with IPR 🎀. Every working group needs to develop and follow its own consensus, and actual treatments will vary as much as they have in the past. However, every working group also needs to take IPR seriously, and consider the needs of the Internet community and the public at large, including possible future implementers and users who will not have participated in the working group process when the standardization is taking place.

5.1. Types of IPR

A primer on the different types of IPR would be large, unreliable, and redundant with other Working Group documents [4][5][6]. For informal exploration, see those documents and other relevant sources on the web. Readers with more serious concerns should consult their legal advisors. In the United States, briefly:

  • Trademarks indicate the sources of goods. Service marks indicate the sources of services. They protect the use of particular marks or similar marks.
  • Copyrights protect the expressions of ideas (not the ideas themselves), in almost any form, and allow "fair use". Copyrights expire but they can be renewed.
  • Patents protect "inventions". They expire (utility patents expire after 20 years), but follow-on patents can cover similar technologies and can have nearly the same implications for use in the Internet as the original patents.

5.2. When to Think About IPR

This memo does not describe IPR procedures for document authors or IPR claimants. Rather, this memo is for working group participants who are trying to decide what to do about IPR claims related to their work. A working group as a whole needs to think about IPR issues:

  • when examining a technology, and deciding whether to initiate work on it.
  • when deciding whether to adopt a draft as a working group document.
  • when choosing between two or more working group drafts that use different technologies.
  • when deciding whether to depend on a technology developed outside the working group.
  • when comparing different kinds of IPR protection.

At each of these times, the working group is strongly encouraged to solicit disclosure of IPR claims and licensing terms 📣. A working group's job will be a lot easier if IPR details are discovered early, but it should realize that IPR claims may appear at any time. Working groups should anticipate that an IPR claimant might choose not to participate in the IETF, but instead to monitor from a distance while the relevant technology is being discussed and evaluated. A working group's knowledge of IPR claims may therefore depend upon when a claimant steps forward during the course of a working group's deliberations.

5.3. IPR as a Technology Evaluation Factor

How do you weigh IPR claims against other issues when deciding whether to adopt a technology? 🤔

The ultimate goal of the IETF is to promote the overall health, robustness, flexibility, and utility of the Internet infrastructure 🌐. We base architectural decisions on our long-term extrapolations of requirements by thinking in these terms. When considering a particular technology, we compare it with other technologies not just for its elegance of design in and of itself, but also for how it fits in the bigger picture. This is done at multiple levels. It is examined for how it fits into the overall design of the working group's output, how it fits into the particular Internet infrastructure area, how it fits with work going on in other areas, and how it fits in the long view of the Internet architecture.

Similarly, when evaluating a technology, working group participants consider IPR claims on it (including possible copyright issues with text describing it). The issue is not whether a particular piece of technology is IPR-impacted, because we use IPR-impacted technology every minute 💖. The question is how much the IPR protection will limit the technology's usefulness in building a robust, highly useful Internet. Thus, the only significant questions are: is the IPR claim relevant, and what are the terms under which the technology can be used? When technology is free from IPR protection the answer is easy. When it is IPR-impacted, some licensing terms make the IPR issues insignificant compared to the engineering issues. Other terms can make a technology unusable even if it is otherwise perfect.

The problem with IPR as a technology evaluation factor is that it is unlikely that a working group, as an entity, can ever claim to have reached consensus on most IPR issues. The IETF as a whole, and a working group as a whole, takes no stance on the validity of any IPR claim. It would be inappropriate for a working group chair to declare that consensus had been reached that, for example, a company's patent was invalid. Individual participants will need to use whatever legal advice resources they have access to in order to form their own individual opinions. Discussions about the validity of IPR may take place under the auspices of the working group, in particular about relative risks of technology choices. Individual participants may take these discussions into account. The working group as a body may not take a stance on validity, but it may make choices based on perceived risk ⚖️.

5.4. Patents versus Pending Patents Applied For ✨

okay so the IETF literally can't ask IPR claimants to explain how they think their patent applies 🙃 when a patent is already granted, the IETF can reasonably expect the patent number and maybe the relevant IETF document sections. that way working group folks can dig into the claims 🔍

if a patent isn't granted yet (or the info is restricted, like for security reasons), there's way less to go on 😬 in most countries, patent applications get published 18 months after filing, but in the USA you can dodge that if you don't also file outside the USA 🫣 some countries make applications public record, but the submitter can change pending claims any time before the patent is granted. so nobody knows what rights will actually be granted until then 💀 and rights can get contested in court, where nothing is final until the courts decide. maybe not even then 😭

so for a pending patent, all the IETF can expect is a disclosure that it exists, the related IETF documents, and possibly the relevant sections plus some statement about licensing terms 🫶

5.5. Applicability: It's Hard to Prove a Negative 🙈

working group participants get to make their own calls on how confident they need to be about whether IPR applies. but perfect knowledge is not a worthwhile goal. it's a vibe-killer 💅

generally, a working group should strive to find out about all IPR claims related to the technologies it's considering, plus at least the general facts about licensing terms. like, is it royalty-free, or "reasonable and non-discriminatory"? 🌸 working group participants should also look into prior art that could counter the IPR claims. but even with exhaustive searches, both outside and inside their employers, it's impossible to prove a technology isn't covered by a particular IPR claim. let alone prove it isn't covered by any claim at all 🤯 anything a working group adopts might turn out to be IPR-impacted later, and the claim might not get discovered for years. claims are open to interpretation even after rights are granted, and drafts can be super fluid right up to last call. IPR issues can sneak in unknowingly at any time 🌀 absolute certainty about IPR claims is rare, periodt.

BUT the confidence level needed to consider IPR when evaluating a technology is often not hard to reach ✨ there are cases where the risk is high (like when licensing terms might be onerous), so you need a high level of confidence about applicability. history shows that most of the time, "rough" confidence is good enough 👑

in every case, licensing terms matter more than whether the IPR claims are valid 💖 licensing terms often don't limit how useful the technology is, and it's hard to be sure about validity anyway. if the licensing terms can be determined to be reasonable, the IPR claims become way less important 🧚

5.6. Licensing Terms 💜

licensing terms range from no license required at all all the way to prohibitive 🌈 working groups generally prefer technologies with IPR considerations in roughly this order. this list is not a rule, and every working group has to factor in its own circumstances 🎀

  • License not required.
  • IPR licensed with no restrictions.
  • IPR licensed with no material restrictions, e.g., no trademark license required.
  • IPR licensed for a particular field of use but with no other material restrictions, e.g., licensed solely for implementations complying with a standard.
  • IPR licensed under royalty-free terms and reasonable and non-discriminatory restrictions.
  • IPR licensed under reasonable and non-discriminatory restrictions. This may include payment of a royalty.
  • IPR which is otherwise licensable.
  • IPR which is not licensable, i.e., which is only available as an implementation.
  • IPR which is not available under any conditions.

many IPR claimants don't like publishing specific license terms 🙄 they might use standard terms for lots of licensees, but they prefer to negotiate terms for some. so don't expect any IPR disclosure statement to lay out detailed blanket terms for licensing 🍓

if a disclosure only lists vague terms, that doesn't mean the terms offered in individual licenses will be any worse than if the disclosure was super specific 🌸 obviously though, if an IPR claimant refuses to suggest any terms at all, the working group is going to struggle to evaluate the future utility of the technology 😩

there's a class of restriction called "reciprocity", where IP can be licensed as long as the licensee is willing to license its own IP in return. these agreements can be more or less specific, and the same or similar terms may be required 🔁 another potential restriction is defensive suspension, where a licensor can revoke or suspend the license if the licensee asserts a patent claim against the licensor. for interpreting any particular reciprocity or related issue, consult your legal adviser ⚖️

words like "reasonable", "fair", and "non-discriminatory" have no objective legal or financial definition 🫠 so actual licensing terms can vary tremendously. IPR claimants have also occasionally claimed there were already enough licenses for a technology to meet "reasonable" multisource and competitiveness requirements. so refusing to grant any licenses to new applicants was, in their words, both fair and non-discriminatory 💀 the best way to find out what an IPR claimant actually means by those terms is to ask them explicitly. it also helps to gather knowledge about licenses actually issued, for that technology or others, and about other experiences with the claimant 🕵️‍♀️

even though IPR claimants often don't like publishing explicit terms, there are levels of vagueness, and individuals or even working groups can sometimes successfully push a claimant toward less vagueness 💪 lots of employers of IETF participants know the IETF prefers explicit terms, and they do feel the pressure to produce them 🫶

if working group participants aren't happy with the confidence level they can get directly about licensing terms for a technology, they can maybe extrapolate from history. for licensed technology to become a draft standard, at least two independent licenses need to have been issued 📜 if the IPR claimant has licensed other technology in the past, there's a record of the terms they're willing to grant, at least in those specific cases. it's weak, but everything counts 🌟

in many jurisdictions that issue patents, inventors have to file applications within 12 months of public disclosure or use of a novel method or process ⏰ since many of those jurisdictions also publish pending applications 18 months after filing, the ability to tell whether claims have been made at all for a technology goes up at 30 months (12 + 18) after its public disclosure or use 🧮

5.7. Third-Party Disclosure of IPR Claims 📣

it's good to notify the IETF about relevant IPR claims even when they aren't your own, and [6] says to do so "as soon as possible" 🚀 but anyone thinking about this should do some preliminary exploration with the affected working group(s) first (see Section 5.7.1). third-party disclosure is a potential denial of service threat to the working group, so it's good form to go slowly at first 🐢

working group participants should know that third-party disclosure can be used, knowingly or unknowingly, to defocus and distract the working group and hinder its progress 👀 they should evaluate third-party disclosures with that in mind. working group chairs should be willing and able to discipline anyone they think is misusing the third-party disclosure system 🙅‍♀️ people who feel they're being unfairly blocked can take the matter up with the Area Directors and/or the IESG 📨

all of the criteria for evaluating IPR claims discussed in the sections above apply to third-party disclosures too, to the extent they can be practiced ✅

5.7.1. Third-Party Disclosure Advice 🎀

this subsection gives advice to people thinking about making third-party disclosures 💌 while it's not required, the actions described here are encouraged to help working groups deal with the possible implications of third-party disclosures. when deciding what (if anything) to do about a third-party disclosure, a working group may consider how closely the discloser followed this advice (for example, when figuring out whether a disclosure is meant mainly to defocus and distract the working group) 🕵️

generally, a potential discloser should exchange mail with the working group chair(s) first, to open the way for discussion 💬 also, if the potential discloser isn't sure the IPR claim applies, this is the time to reach some kind of agreement with the working group chair(s) before saying anything publicly 🤫 after talking with the chair(s), the potential discloser should bring the issue to the attention of the working group, and to the IPR claimant too if that isn't too difficult. that discussion should help the potential discloser become more sure, one way or the other 🧠 if the potential discloser is sure the discovered IPR claim applies, and the IPR claimant doesn't submit a first-party disclosure itself, then the potential discloser is encouraged to submit a third-party disclosure 📝

IP often applies to more than one working group 🌐 someone thinking about a third-party disclosure should consider which other working groups might be affected, and communicate with them the same way 🫂

don't bring up IPR issues that are unrelated to the areas the working group is focusing on at that time 🚫 don't bring IPR claims to the working group's attention just in case they might be relevant in a few months. only do it if they have implications for current work ⏳ messages to the working group list should be substantive, and a single message should focus on one specific issue. they can reference multiple claims or patents related to that issue 📬

6. Security Considerations 🔐

this memo is about IETF process, not any particular technology 🧩 there are security considerations when adopting any technology, whether or not IPR claims are asserted against it. a working group should take those security considerations into account as one part of evaluating the technology, just like IPR is one part. but these are not security issues with IPR procedures 🛡️ so keep those two things separate, bestie, because mixing them up is how things get messy 💥🌸

7. Acknowledgments 💖

okay so the author wants to shout out the IETF IPR Working Group for helping out 🫶 Huge. They also thank everyone who gave extensive comments and suggestions, and the list is iconic: Robert Barr, David Black, Scott Bradner, Jorge Contreras, Paul Gleichauf, Keith Moore, Russell Nelson, Jon Peterson, Randy Presuhn, Pekka Savola, Valerie See, Bob Wyman, and Joe Zebarth. Main character energy for all of them ✨

8. References 📚

8.1. Normative References

  • [1] Huitema, C. and P. Gross, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994.
  • [2] Postel, J., "Addendum to RFC 1602 -- Variance Procedure", BCP 2, RFC 1871, November 1995.
  • [3] Kastenholz, F., "Variance for The PPP Connection Control Protocol and The PPP Encryption Control Protocol", BCP 3, RFC 1915, February 1996.
  • [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [5] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004.
  • [6] Bradner, S., Ed., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004.

8.2. Informative References

  • [7] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.

9. Author's Address 🎀

Scott Brim lives at:

Scott Brim
Cisco Systems, Inc.
146 Honness Lane
Ithaca, NY  14850
USA

EMail: sbrim@cisco.com

Copyright (C) The Internet Society (2004). 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.

Important legal bit, bestie 💅: 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 🦋

okay so the IETF doesn't take a side on whether any Intellectual Property Rights (or other rights) that might be claimed about the tech in this doc are valid or how wide they are, and it also doesn't say it looked for any of them 🙈 whether anyone can get a license is a whole different question. The procedures for rights in RFC docs live in BCP 78 and BCP 79, so go check there 🔥

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be available, and the results of any attempt to get a general license or permission for implementers or users of this spec can be found in the IETF online IPR repository at http://www.ietf.org/ipr.

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed 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, Internet Society! 🫶

📦 where this page comes from