RFC 4053

Procedures for Handling Liaison Statements to and from the IETF

📅 published April 2005, from ietf

RFC 4053: Procedures for Handling Liaison Statements to and from the IETF 💌

okay bestie, this one is a Best Current Practice (it's BCP 103 🎀), so it's the IETF's official "here's how we do it well" guide. It's from April 2005, written by S. Trowbridge (Lucent Technologies), S. Bradner (Harvard University) and F. Baker (Cisco Systems). It's a Network Working Group doc, and it doesn't list anything it obsoletes or updates. Lowkey no drama there 💅

Status of This Memo ✨

This doc is an Internet Best Current Practice for the Internet Community, and it's literally asking you all for discussion and suggestions for improvements 🫶 Distribution of this memo is unlimited, so share it with anyone.

Copyright (C) The Internet Society (2005).

Abstract 💖

This doc explains how to properly handle incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and how to write liaison statements that go from the IETF to those same SDOs, consortia and industry fora. The whole point is that the IETF can work well with other orgs in the international standards community 🌈

The IETF expects liaison statements from all kinds of organizations, and it may choose to respond to a lot of them. It's only obligated to respond if there's an agreed liaison relationship, though. ngl that's a very reasonable boundary 🙈

Table of Contents 📋

   1. Introduction ....................................................3
   2. Liaison Statements and Their Handling ...........................3
      2.1. Definitions ................................................3
      2.2. Liaison Statements .........................................4
           2.2.1. Contents of a Liaison Statement .....................4
                  2.2.1.1. Envelope Information .......................4
                  2.2.1.2. Liaison Content ............................5
      2.3. Addressee Responsibilities .................................6
      2.4. Lifetime of a Liaison Statement ............................7
   3. Tools for Handling Liaison Statements ...........................7
      3.1. Liaison Statements from Other SDOs, Consortia, and
           Fora to IETF ...............................................7
           3.1.1. Liaison Statement Submission ........................8
           3.1.2. Mechanism for Displaying Liaison Statements .........9
      3.2. Communicating IETF Information to Other SDOs,
           Consortia, and Fora ........................................9
           3.2.1. Spontaneously Generating Liaison Statements
                  to Other ............................................9
                  3.2.1.1. Transmitting IETF Documents to
                           Other Organizations .......................10
                  3.2.1.2. Requests for Information ..................10
                  3.2.1.3. Requesting Comments on Work in Progress ...11
                  3.2.1.4. Requests for Other Actions
                           (Besides Comments on IETF Drafts) .........11
           3.2.2. Responding to Incoming Liaison Statements ..........11
                  3.2.2.1. Responding to Requests for Information ....11
                  3.2.2.2. Responding to Requests for Comments .......12
                  3.2.2.3. Responding to Request for Action ..........12
                  3.2.2.4. Generating Liaison Statements .............13
   4. Security Considerations ........................................13
   5. Acknowledgements ...............................................14
   A. Implementation Road map ........................................15
      A.1. Phase I: Initial Implementation ...........................15
           A.1.1.   Displays .........................................15
           A.1.2.   Actions on Submission ............................16
   B. Phase II: Additional Instrumentation and Responses to
      Usage Experience ...............................................17
   Normative References ..............................................17

1. Introduction ✨

This doc is all about how liaison statements get generated and handled between the IETF and other SDOs, so the IETF can really collaborate with other orgs in the international standards world 🦋 These statements mostly go between the IETF and orgs the IAB has set up a liaison relationship with (see [RFC4052]), but other orgs aren't ruled out. This procedure covers every liaison statement received from an SDO, even if there's no formal liaison arrangement between that SDO and the IETF. Without a formal arrangement, though, the IETF doesn't have to respond 💅

Rolling this out happens in at least three phases 🧚 The first phase was a prototype built by Sunny Lee of Foretec, following the best tradition of "rough consensus and running code," and it was developed alongside this spec. Phase two turns that prototype into an operational tool. That tool doesn't have an automated tracking tool yet, so the liaison manager runs tracking in their own way. Phase three adds that tracking tool.

The specific tools and what they do in this doc are just one possible way to automate these processes. Tools change over time, so the descriptions here are only examples and are not a normative part of this spec 🫶

2. Liaison Statements and Their Handling 💌

Let's start by defining what a liaison statement is (and isn't) so everyone has realistic expectations. The expectations in this section are normative for any liaison statement an SDO sends to the IETF 🔥

2.1. Definitions 📖

Here's the glossary so we're all on the same page:

Addressee: The Working Group(s) (WG) or other party(s) in the IETF that a liaison statement is addressed to.

Assignee: The person responsible for acting on a liaison statement. It starts with either the person it was addressed to or the chair of the group it was addressed to. The task can be reassigned to someone in the same group or a different one if that makes sense 🎀

Liaison manager: A person designated to manage the relationship between the IETF and a peer organization, making sure communication stays up, productive, and timely. This is defined by sections 2.2 and 3 in [RFC4052] 💜

Liaison statement: A letter, as described in this document, that gets exchanged between organizations 💖

2.2. Liaison Statements 💌

A liaison statement is a business letter one standards org sends to another. The orgs can be at any level (WG, Area, etc.) Usually the sender and the receiver are peers. A liaison statement can have any purpose, but generally it's to ask for information, leave a comment, or request an action 🌸

2.2.1. Contents of a Liaison Statement 📋

Liaison statements can be super formal or pretty casual, depending on the rules of the body writing them. Still, every liaison statement has certain info in it, kind of like a regular business letter. Here's what it includes:

2.2.1.1. Envelope Information 💌

The following fields describe the properties of the liaison statement.

2.2.1.1.1. From: 🧚

This tells you which body it came from. For example, it might be an IETF WG or Area, an ITU-T Study Group, Working Party, or Question, and so on. In this doc, that body is called the "sender" 💖

2.2.1.1.2. To: 🎀

This tells you which body it's going to. In this doc, that body is called the "addressee" 🦋

2.2.1.1.3. Title: ✨

This is a short statement (usually one line) of the context and content. It's the main vibe check 🌈

2.2.1.1.4. Response Contact: 💅

This is the email address where any response should be sent 💌

2.2.1.1.5. Technical Contact: 🫶

This lists one or more email addresses (persons or lists) that can be contacted to clarify the liaison statement 🔥

2.2.1.1.6. Purpose: 🍓

A liaison statement generally has one of three purposes, and it'll clearly say which one with one of these labels. Okay, I'm counting four here, so it's giving "main character with a cameo" 🙈

For Information: The statement informs the addressee of something and expects no response.

For Comment: The statement asks the addressee for commentary, usually within a stated time frame.

For Action: The statement asks the addressee to do something on the sender's behalf, usually within a stated time frame.

In Response: The statement includes a response to a liaison statement from the peer organization about one or more of its documents, and it expects no further response.

2.2.1.1.7. Deadline: ⏰

Statements that ask for comment or action will say when the comment or action is needed. If the addressee can't get it done in the stated period, the polite move is to reply with a more doable deadline or an alternative course of action. That's just good manners, bestie 💖

2.2.1.2. Liaison Content 📝

These fields are the actual substance of the liaison statement. IETF participants use all sorts of systems, so document formats that aren't universally readable are a problem 😭 Because of that, documents enclosed with the body or attachments should be in PDF, W3C HTML (without proprietary extensions), or ASCII text. If they were originally in a proprietary format like Microsoft Word, the file can still be sent, but it should come with a generally readable file too 🌸

2.2.1.2.1. Body: 💌

Just like any business letter, the body has the right content explaining the issues or questions at hand 💖

2.2.1.2.2. Attachments: 📎

If there are attachments, they can be documents sent along with the liaison statement, or URLs pointing to similar documents, including Internet Drafts 🦋

More liaison drama coming in part 2! 🫶🌈

2.3. Addressee Responsibilities ✨

okay so the addressee of a liaison statement has the same responsibilities as anyone who gets a business letter 💌 A liaison statement needs appropriate consideration of what it says, and if a reply is requested and there's an appropriate relationship, a courteous, authoritative reply within the expected time frame 🎀 The reply can be that the info was useful or not useful, that the requested action has been accomplished, that it'll be accomplished by a specified date, that it won't be done for a specific reason, an answer to a question that was posed, or any other appropriate reply 💅

A liaison statement, like any other temporary document, must be considered for its relevance, importance, and urgency 🦋

One hopes a liaison statement gets sent to the right organization, but that can't be guaranteed 🙃 An SDO might send one to a specific IETF Area whose Area Director (AD) decides it's better handled by one of the WGs, or it might land with one WG when it should have gone to another. If a liaison statement arrives looking misdirected, the assignee should promptly ask the liaison manager to redirect it appropriately. In some cases a liaison statement may need consideration by multiple groups within the IETF; in those cases, one assignee takes the lead and responsibility for developing a response 🫶

Liaison Statements are always important to the body that sent them 💜 Once it's arrived at the appropriate body, it may be more or less important to the addressee depending on its contents and the expertise of the sender. If the liaison statement seeks to influence the direction of a WG's development, it should receive the same consideration that any temporary document receives. The WG chair may ask the sender's contacts to make their case to the IETF WG in the same way that an author of an internet draft makes his or her case 👑

The urgency of a liaison statement is usually reflected in its deadline ⏰ A liaison statement for informational purposes may have no deadline; in that case, a courteous "thank you" liaison statement is necessary to tell the sender that it was received. The WG may then inform itself of the contents and close the document. A liaison statement specifying a deadline, however, gives the addressee a finite opportunity to influence the activity of another body; if it fails to react in a timely fashion, it may miss that opportunity 😭

2.4. Lifetime of a Liaison Statement 🌸

A liaison statement is a temporary document, much like an internet draft 🧚 If it affects IETF output, the normal expectation is that the resulting RFC will contain relevant information that remains pertinent. Keeping liaison statements that have been completely dealt with mostly just hides new ones and creates the appearance of not dealing with them 🙈

However, unlike an internet draft, liaison statements are often the only record the IETF has of the communication with the peer SDO 📜 So some liaison statements get referred to for relatively long periods of time.

As a result, the IETF will archive liaison statements that have been fully dealt with, along with any attachments that may have been relevant, but it'll do so in a manner obviously distinct from current liaison statements 🗂️

3. Tools for Handling Liaison Statements 🛠️

Some tools have been developed for the IETF, and development is expected to continue ✨ This section describes the basic tool and its intended use.

3.1. Liaison Statements from Other SDOs, Consortia, and Fora to IETF 📬

Handling a liaison statement is more weighty than handling a business letter, because it's important to a relationship with another SDO that was established by the IAB 💖 To manage liaison statements, the IETF will offer three electronically accessible facilities: a form for submission of liaison statements, a mechanism organizing their contents and making them accessible, and a tracking system. Initially, the tracking system will be a manual procedure used by the liaison manager; in the future, this should be automated.

3.1.1. Liaison Statement Submission 📝

The IETF Secretariat will provide an electronic method for submission of liaison statements.

The liaison statement submission mechanism is a form that requests the information listed in Section 2.2.1 from the user.

Submitting that information results in the following actions:

  • creation of a display mechanism containing the envelope data in Section 2.2.1.1 and URLs pointing to the items from Section 2.2.1.2, plus an indication of whether the liaison statement has been replied to and, if so, on what date,
  • the addition of a URL to the "outstanding liaison statements" summary mechanism,
  • when an automated tracking system has been implemented, a tickler/status entry in the tracking system, assigned to the relevant chair or AD,
  • an email to the assignee, copying:
    • the liaison statement's technical contacts
    • the supervisor of the assignee (if it is to a WG, the relevant ADs; if to an AD, the IETF Chair),
    • the liaison manager for the sending SDO,
    • an alias associated with the assignee (WG/BOF or other open mailing list, Area Directorate, IESG, IAB, etc.)

This email should contain the URL to the liaison statement mechanism, text indicating that the liaison statement has arrived, a request for appropriate consideration, and, if a deadline is specified, a reply by the deadline 💌

The assignee can interact with the liaison manager and the tracking system (once implemented), including replying, changing dates, reassignment, closing the liaison statement process, and so on 🙌

The liaison manager's or tracking system's "tickle" function periodically reminds the assignee by email that the liaison statement hasn't been closed yet ⏳ This tickle email copies everything above except the associated mailing alias.

3.1.2. Mechanism for Displaying Liaison Statements 🖥️

The IETF site has a section for current liaison statement activity 💫 This consists of:

  • A submission mechanism,
  • A status/management mechanism for each active or recently closed liaison statement, and zero or more associated files.

The status/management mechanism contains a simple frame showing the title of the liaison statement, the URL for its mechanism, and the organizations it's from and to.

The display for the liaison statement itself contains:

  • the liaison statement envelope information (Section 2.2.1),
  • direct content (Section 2.2.1),
  • URLs for the various associated files
  • current status of the liaison statement: who it's assigned to, its due date, and its status,
  • a pointer to the liaison manager and the tracking system entry for the liaison statement,
  • reply-generation mechanism (see Section 3.2.2.4)

3.2. Communicating IETF Information to Other SDOs, Consortia, and Fora 📤

This includes liaison statements sent in reply to liaison statements from other bodies, and liaison statements being originated by the IETF 🌈

3.2.1. Spontaneously Generating Liaison Statements to Other Organizations 💡

Liaison Statements can be generated at a WG, Area, or IETF level to another organization. The respective (co)chair(s) are responsible for judging the degree of consensus for sending a particular liaison statement and for deciding its content. The amount of consensus required to send a liaison statement varies greatly depending on its content 🧐 This section gives some rough guidance on how much consensus should be sought before sending a liaison statement to another organization.

3.2.1.1. Transmitting IETF Documents to Other Organizations 📚

The simplest case of approving a liaison statement sent from the IETF is when the information being transmitted is an IETF document that already has some level of agreement within the IETF 🥰 The process the document has already gone through to reach its current status assures the necessary level of consensus. Any Standards Track RFC (Draft Standard, Proposed Standard, Internet Standard, BCP), and any WG document expected to be placed on the standards track, may be transmitted without concern ✅

Informational documents may also be exchanged readily when they represent a WG position or consensus, such as a requirements or architecture document.

In all cases, the document status must be appropriately noted. In the case of a WG Internet Draft, it must be clear that the existence of the draft only indicates that the WG has accepted the work item and, as the standard disclaimer says, the actual content can be treated as nothing more than Work in Progress 🚧

Individually submitted Internet Drafts, Experimental or Historical RFCs, and non-WG informational documents should not be transmitted without developing further consensus within the relevant group, as these documents cannot be truthfully represented as any kind of IETF position. 🙅‍♀️

3.2.1.2. Requests for Information 🔍

Another type of liaison statement that can be generated without extensive consensus building on the email list is a request for information. The (co)chair(s) can generate such a liaison statement when they recognize, from the activities of the group, that some additional information would help, for example to resolve an impasse. (Basically: don't waste time arguing over what another SDO's document really means or intends. Just ask the other SDO and base further work on the "official" answer 🤷‍♀️)

Other requests for information may ask for access to certain documents of other organizations that are not publicly available 🔐

3.2.1.3. Requesting Comments on Work in Progress 🗣️

There may be cases when a document under development in the IETF could benefit from input from experts in another relevant SDO, consortium, or forum. Generally this is done before the text is "fully cooked," so that input from experts in another organization can be included in the final result 🍳 Comments would generally be solicited for a standards track WG Internet Draft, and some level of consensus should be reached on the WG or other open mailing list that it's appropriate to ask another organization for comments on an IETF draft.

3.2.1.4. Requests for Other Actions (Besides Comments on IETF Drafts) 🎯

There are many other kinds of actions that might reasonably be requested of another organization:

  • In the case of overlapping or related work in another organization, a request could be made that the other organization change something to align with the IETF work.
  • A request could be made for another organization to start a new work item (on behalf of the IETF).
  • A request could be made for another organization to stop a work item (presumably because it overlaps or conflicts with other work in the IETF).
These kinds of requests are quite serious 💀 They can certainly be made when appropriate, but they should only be made when there is the clearest possible consensus within the particular WG, Area, or within the IETF at large.

3.2.2. Responding to Incoming Liaison Statements 💌

Okay so any incoming liaison statement that says it's for "Comment" or for "Action" needs a response by the deadline 🚨. Other liaison statements can get a reply too, but a reply is generally optional. It's the job of the (co)chair(s) of the addressed organization to make sure a response actually gets generated by the deadline 💅.

3.2.2.1. Responding to Requests for Information 🔍

If another organization asks for info that can be found in an IETF document of the types listed in Section 3.2.1.1, the (co)chair(s) of the addressed group can send it back in a reply, and they indicate the level of agreement for that document. Lowkey the easiest kind of reply 🧚

3.2.2.2. Responding to Requests for Comments 💬

If an incoming liaison statement requests comments on a document from another organization, a discussion will happen on the mailing list where participants can drop their comments 🍓

If a clear consensus is evident from the pattern of comments made to the mailing list, the (co)chair(s) can summarize the conclusions in a reply liaison statement back to the originating organization ✨

If no clear consensus is evident from the pattern of comments on the mailing list, or if there is no further discussion, a response is still due to the originator 🥺 A summary of the email comments, or lack of interest in the issue, should be created and sent to the originator, and represented as "collected comments" rather than a consensus of the IETF group to which the liaison statement was addressed. It is possible to send this kind of a reply even if some of the comments are contradictory. Messy but valid 💅

3.2.2.3. Responding to Request for Action 🔥

A request for Action is a fairly serious thing 😭 Examples of the kinds of actions that may be expected are:

  • In the case of overlapping or related work in another organization, another organization may request that the IETF align its work with that of the other organization.
  • A request could be made for IETF to undertake a new work item.
  • A request could be made for IETF to stop a work item (presumably because it overlaps or conflicts with other work in the originating organization).

Consensus of the receiving group within IETF is clearly necessary to fulfill the request. Fulfilling the request may require a great deal of time and multiple steps, for example, if initiating or stopping a work item requires a charter change 🫠

There is, of course, no requirement that IETF perform the action that was requested. But the request should always be taken seriously, and a response is required 🫶 The originating organization must always be informed of what, if anything, the IETF has decided to do in response to the request. If the IETF decides not to honor the request, or to honor it with modifications, the response should include the reasons and, if applicable, the alternate course of action.

For tasks that require a great deal of time, it may be necessary that several liaison statements be sent back to the originating organization to report the status of the work and the anticipated completion time. The first of these liaison statements must be generated by the deadline indicated in the incoming liaison statement ⏰

3.2.2.4. Generating Liaison Statements 📝

IETF participants, usually WG chairs, ADs, or other officials, need to be able to send liaison statements to other SDOs 🦋 The mechanism described in Section 3.1.2, listing appropriate contacts in other SDOs with which the IAB has established liaison relationships, provides that capability.

As a convenience, the liaison statement page described in Section 3.1.2 may be used to generate a reply. If a person (usually a WG chair or an AD) selects "reply", a new liaison statement page is generated from the existing one, reversing the addressing information. IETF documents should be referenced by URL, such as http://www.ietf.org/internet-drafts/>file< or ftp://ftp.rfc-editor.org/in-notes/>file<.

The process of generating and approving transmission of liaison statements is a matter of IETF process and is specified in [RFC4052] 📖

4. Security Considerations 🚨

One of the key considerations in developing this process has been the possibility of a denial of service attack on the IETF and its processes. Historically, the IETF has not always handled liaison statements effectively, resulting in people working in other organizations becoming frustrated with it. Various organizations have also used the liaison statement process to impose deadlines on IETF activities, which has been frustrating for all concerned: the IETF because it does not accept such deadlines, and other organizations because they feel ignored 😤

For this reason the submission process is automated. While the IETF cannot rate-limit the submitters, it can manage its internal pipelines 🛡️

This issue is exacerbated by the lack of any authentication on the part of the submitter. However, the IAB considers it important to be able to accept liaison statements whether or not a liaison relationship exists, so authentication of submitters is not an effective control. ⚠️

5. Acknowledgements 🎀

This text has been prompted by discussions with numerous individuals within IETF and other SDOs and fora, including Gary Fishman and Bert Wijnen. It has been developed in cooperation with [RFC4052], which is to say with the express cooperation of the chair of the IAB, Leslie Daigle. Personal experiences and some "miscues" in coordinating work across ITU-T Study Group 15 and the IETF Sub-IP Area have also motivated this work. Some drafts addressing individual problems (for example, RFC 3427) make it clear that a more general, consistent solution is needed for dealing with outside organizations. Certain ideas have been borrowed from these texts 🌸

Barbara Fuller, Sunny Lee, and Michael Lee developed a prototype and commented in detail on the document. Their inputs directly resulted in the appendices describing the implementation road map 💜

Appendix A. Implementation Road Map 🗺️

This section documents the development program as of the time of the writing of this document. It is not normative.

A.1. Phase I: Initial Implementation 🌈

A.1.1. Displays 🖥️

The descriptions of the required displays in Section 3.1.1 and Section 3.1.2 call for two sets of displays: one for the public (for viewing liaison statements), and one for submitters (for managing liaison statements).

Displays for public view of liaison statements include:

  • A Liaison Statements Web page that lists all incoming and outgoing liaison statements (specific fields TBD). The title of each liaison statement is a link to the details page for that liaison statement.
  • A detail page for each liaison statement that contains:
    • All of the information specified in the subsections of Section 2.2.1.
    • Links to all attachments that accompanied the liaison statement or to documents that are mentioned in the statement but were not provided as part of the submission.
    • Links to all related liaison statements (e.g., replies).

Displays for submitting and managing liaison statements include:

  • A summary page that offers mechanisms for:
    • Creating and submitting a new liaison statement.
    • Editing a liaison statement that the user has previously created and submitted.
    • Acting on a liaison statement that has been assigned to the user.
  • A template for creating and submitting a liaison statement. This template allows the user to enter the information specified in Section 2.2.1. The user is able to access the template at any time (from a list of liaison statements that the user has previously created and submitted), and update and resubmit the information.
  • A detail page for managing a liaison statement assigned to the user. This page is similar to the details page available to the public. However, it also includes:
    • A mechanism for replying to the liaison statement (initial implementation).
    • A link to a liaison statement tracking mechanism (future implementation).

A.1.2. Actions on Submission ⚡

Submission of a liaison statement results in the following actions:

  • The information is uploaded to the database.
  • An e-mail message with the content specified in Section 3.1.1 is sent to the addressee with copies to the addresses specified in Section 4.1, and to the Secretariat (as specified in [RFC4052]).
  • The liaison statement is added to the list on the Liaison Statements Web page.
  • Two detail pages are created for the liaison statement: one for the public (to view the liaison statement), and one for the sender and the assignee (to manage the liaison statement).

As specified in Section 3.2.2.4, when a user selects reply on the details page of a liaison statement, a template for creating and submitting a new liaison statement is generated from the existing one that copies "From" to "To" and specifies the respondent as the individual the response is coming "From". Submission of this reply liaison statement results in the same set of actions as submission of any new liaison statement. In addition, a link to the details page of this liaison statement is added to the list of related liaison statements on the details pages (both public and management) of the original liaison statement (i.e., the one to which the user replied) 🔗

Appendix B. Phase II: Additional Instrumentation and Responses to Usage Experience 🔮

This section is for information, and is not normative.

The intended features of the future liaison statement tracking system are discussed in Section 3.1. They include mechanisms for:

  • Designating an assignee; the assignee is initially a person associated with the body (IAB, IESG, Area, WG, etc.) to which the liaison statement is addressed, but may subsequently be changed by an IETF participant.
  • Indicating the status of the liaison statement (e.g., actions required, actions taken, etc. Specific options TBD).
  • Sending ticklers to the assignee when action is required (with copies to whomever is appropriate).
  • Changing the status of the liaison statement, the deadline, or other attributes.
  • Reassigning responsibility.
  • Closing the liaison statement.

Normative References 📚

[RFC4052]  Daigle, L., "IAB Processes for Management of Liaison
           Relationships", RFC 4052, April 2005.

Authors' Addresses 🫶

Stephen J. Trowbridge
Lucent Technologies
1200 West 120th Avenue, Suite 232, Room 34Z07
Westminster, Colorado  80234-2795
USA

Phone: +1 303 920 6545
Fax:   +1 303 920 6553
EMail: sjtrowbridge@lucent.com


Scott Bradner
Harvard University
29 Oxford St.
Cambridge, Massachusetts  02138
USA

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


Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California  93117
USA

Phone: +1-408-526-4257
Fax:   +1-413-473-2403
EMail: fred@cisco.com

Copyright (C) The Internet Society (2005). 🎀

This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights. ✨

This document and the info inside it are provided on an "AS IS" basis. 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. ⚠️ That includes, but isn't limited to, any warranty that using the information here won't infringe any rights, and any implied warranty 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 someone might claim over the tech in this document are valid, or how far they reach. It also doesn't say whether licenses for those rights exist. It hasn't made any independent effort to find such rights either. 💅 If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79. 📚

Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses that are going to be made available, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🌸 The same goes for the result of any attempt to get a general license or permission to use proprietary rights, made for implementers or users of this specification. 🧚

The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology 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. 👑✨

📦 where this page comes from