One document matched: draft-polk-ipr-disclosure-04.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="info" ipr="trust200902" docName="draft-polk-ipr-disclosure-04">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front>
<title abbrev="IPR Disclosure">Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules</title>
<author initials="T." surname="Polk" fullname="Tim Polk">
<organization>National Institute of Standards and Technology</organization>
<address>
<postal>
<street>100 Bureau Drive, MS 8930</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899-8930</code>
<country>USA</country>
</postal>
<email>tim.polk@nist.gov</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<date day="28" month="May" year="2012"/>
<abstract>
<t>The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream is essential to the accurate development of community consensus. However, this process is not always followed by IETF participants. Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. This document describes some strategies for promoting compliance with the IPR disclosure rules. These strategies are primarily intended for use by area directors, working group chairs, and working group secretaries.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t>The disclosure process for intellectual property rights (IPR) in documents produced within the IETF stream <xref target='RFC5741'/> is essential to the efficient and accurate development of community consensus. In particular, ensuring that IETF working groups and participants have as much information as possible regarding IPR constraints, as early as possible in the process, increases the likelihood that the community can develop an informed consensus regarding technical proposals. Statements to that effect appear in both the second and third revisions of the Internet Standards Process (<xref target='RFC1602'/>, Section 5.5, Clause (B) and <xref target='RFC2026'/>, Section 10.4, Clause (B)).</t>
<t>However, sometimes IPR disclosures do not occur at the earliest possible stage in the IETF process. There are many reasons why an individual might not disclose IPR early in the process: for example, through a simple oversight, to introduce delay, or to subvert the emergence of consensus.</t>
<t>Regardless of the cause or motivation, noncompliance with IPR disclosure rules can delay or even derail completion of IETF specifications. Disclosure of IPR after significant decisions, such as Working Group Last Call (WGLC), might lead to reconsideration of those actions. As one example, a working group (WG) might change course and use a previously rejected technical proposal with less onerous licensing requirements. Such "course corrections" produce unnecessary delays in the standardization process.</t>
<t>This document suggests some strategies for promoting compliance with the IETF's IPR disclosure rules and thereby avoiding such delays. These strategies are primarily intended for use by area directors (ADs), WG chairs, and WG secretaries.</t>
<t>These strategies are focused on promoting early disclosure by document authors, since late disclosure involving authors has historically caused significant delays in the standardization process. Many of these strategies also promote early disclosure by other IETF contributors.</t>
<t>Naturally, even if ADs, WG chairs, and WG secretaries do not apply the strategies described in this document, IETF contributors are still bound by the rules defined in BCP 79 (see <xref target='RFC3979'/> and <xref target='RFC4879'/>). This document does not modify those rules, nor does it normatively extend those rules; it merely provides suggestions intended to aid ADs, WG chairs, and WG secretaries.</t>
<t>By intent, this document does not claim to define best current practices; instead, it suggests strategies that ADs, WG chairs, and WG secretaries might find useful. With sufficient use and appropriate modification to incorporate the lessons of experience, these strategies might someday form the basis for documentation of best current practices.</t>
<t>This document does not consider the parallel, but important, issue of potential actions that can be taken by the IETF itself for lack of conformance with the IETF's IPR policy. That topic is discussed in <xref target='Sanctions'/>.</t>
<t>At the time of this writing, the Internet Research Task Force (IRTF) follows the same IPR disclosure rules as the IETF (see <eref target='http://irtf.org/ipr'/>); therefore, the stategies described here might also be appropriate for use by IRTF Research Group chairs.</t>
<section title="Terminology" anchor='intro-terms'>
<t>This document relies on the definitions provided in Section 1 of <xref target='RFC3979'/>.</t>
<t>The term "formal disclosure" refers to an IPR disclosure statement that has been officially submitted by using the IPR disclosure tools currently available at <eref target='http://www.ietf.org/ipr/file-disclosure'/> or by sending a message to <eref target='mailto:ietf-ipr@ietf.org'/>. The term "informal disclosure" refers to a statement that is provided in a less official manner, such as orally during a presentation, in writing within presentation materials, or posted via email to the relevant discussion list before a presentation.</t>
<t>Since this document is purely informational, by intent it does not use the conformance language described in <xref target='RFC2119'/>.</t>
</section>
</section>
<section title="Background" anchor='background'>
<t>The responsibilities of IETF contributors regarding IPR disclosure are documented in <xref target='RFC3979'/> and <xref target='RFC4879'/>. These documents do not assign any further responsibilities to ADs, WG chairs, and WG secretaries, other than those imposed by their roles as contributors or participants. However, late disclosure of IPR has a direct impact on the effectiveness of working groups, WG chairs, and ADs.</t>
<t>According to <xref target='RFC2418'/>, WG chairs are responsible for "making forward progress through a fair and open process" and ADs are responsible for "ensuring that working groups in their area produce ... timely output"; in addition, because WG chairs can appoint one or more WG secretaries to help them with the day-to-day business of running the working group (see <xref target='RFC2418'/>), some of the actions suggested in this document might fall to WG secretaries.</t>
<t>IPR disclosure at the earliest possible time is an essential feature of a "fair and open process", and late disclosure can impede timely output since it can cause the WG to revisit previous decisions, needlessly revise technical specifications, and face the prospect of appeals. To better fulfill their responsibilities in the IETF standards process, ADs, WG chairs, and WG secretaries might wish to adopt strategies to encourage early disclosure consistent with the responsibilities established in <xref target='RFC3979'/> and <xref target='RFC4879'/>, such as the strategies described in this document.</t>
</section>
<section title="Strategies for Working Group Documents" anchor='wg'>
<t>Building upon the framework provided in <xref target='RFC3669'/>, this section identifies opportunities to promote IPR disclosure within the document lifecycle for IETF working group documents. In general, these opportunities are encountered during socialization, working group adoption, Working Group Last Call (WGLC), and IETF Last Call. The strategies described in this section are primarily implemented by WG chairs. (The exceptions are strategies for IETF Last Call, which would be implemented by ADs.) In cases where the WG secretary creates meeting agendas or initiates consensus calls, the secretary might also implement these strategies.</t>
<section title="Presenting an Internet-Draft at an IETF Meeting" anchor='wg-present'>
<t>The first opportunity to encourage early IPR disclosure might occur even before a technical proposal becomes a working group document.</t>
<t>When IETF participants wish to socialize a personal draft in hopes of future adoption by a working group, one common strategy is to request a slot on the agenda at an upcoming face-to-face meeting. Before the community commits resources to reviewing and considering the draft, it is very reasonable for the WG chairs to confirm (often via email) that all IPR disclosures have been submitted. The chairs ought to request confirmation from each of the authors and listed contributors, especially if those individuals are associated with multiple organizations.</t>
<t>If the necessary disclosures have not been submitted, the chairs have a choice: deny the agenda slot unless formal IPR disclosure statements are submitted, or insist on informal disclosure. One factor in this decision could be the number of revisions that have occurred: the chairs might wish to permit presentation of a -00 draft with informal disclosure, but not after a draft has gone through multiple revision cycles. If informal disclosure is allowed, the chairs ought to make sure that the disclosure is documented in the minutes, and ought to encourage submission of formal disclosure statements after the meeting.</t>
<t>In some cases, an IETF participant has not yet submitted an Internet-Draft but might still request a slot on the agenda to discuss a proposal for a new draft, or a new feature for an existing working group document. Here again, it is very reasonable for the WG chairs to confirm, before approving the agenda slot, that all IPR claims have been disclosed (likely in an informal manner as described above, since the participant has not yet made a Contribution as defined by the Internet Standards Process <xref target='RFC3979'/>).</t>
</section>
<section title="Requesting WG Adoption" anchor='wg-adopt'>
<t>When a technical proposal is considered for adoption by a working group, the chairs have an opportunity to confirm (or reconfirm) IPR compliance with authors and listed contributors. In addition, the chairs might wish to explicitly ask the WG participants if anyone is aware of IPR that is associated with the proposal.</t>
</section>
<section title="Requesting WG Last Call" anchor='wg-wglc'>
<t>Working Group Last Call is a particularly significant milestone for a working group document, measuring consensus within the working group one final time. If IPR disclosure statements have not been submitted, the judgement of consensus by the chairs would be less than reliable. Even if procedures such as those described above have been implemented to promote IPR disclosure during socialization and adoption, features might have evolved in a way that introduces new IPR concerns. In addition, new participants with knowledge of IPR claims might have become active in the working group. Therefore the WG chairs might wish to reconfirm with each of the authors and listed contributors that appropriate IPR disclosure statements have been filed, even if they all work for the same organization. The chairs might also wish to include a reminder about the importance of IPR disclosures in any WGLC message communicated to the working group. (Note: If IPR disclosure statements have been filed, the chairs might wish to include a link in the WGLC message to ensure that the consensus call reflects this information.)</t>
</section>
<section title="AD Review" anchor='wg-review'>
<t>After successfully completing WGLC, a working group document is forwarded to the appropriate Area Director for AD review, with a request that the AD process the document for publication as an RFC. Such a publication request is accompanied by a Document Shepherd Write-up as required by <xref target='RFC4858'/> using the template found at <eref target='http://www.ietf.org/iesg/template/doc-writeup.html'/>. At the time of this writing, the template asks the document shepherd to answer the following question:</t>
<t>
<list style='empty'>
<t>(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.</t>
</list>
</t>
<t>Additionally, the AD can ask the WG chairs whether they took explicit action to promote disclosure of IPR. If the answer to the write-up question is not favorable, or if the chairs did not take any of the actions listed above, the AD might choose to contact the authors and listed contributors to confirm that the appropriate IPR disclosure statements have been filed before advancing the document through the publication process.</t>
</section>
<section title="IETF Last Call" anchor='wg-lc'>
<t>IETF Last Call is the mechanism used by the the AD and the IESG as a whole to gauge IETF-wide consensus. It is critical that the community have easy access to all related IPR statements when considering an Internet-Draft. The current tools automatically include the URL for each IPR statement explicitly linked to the draft when the default IETF Last Call message is generated. If the AD edits this message, the links to IPR disclosure statements ought to be preserved.</t>
</section>
</section>
<section title="Strategies for Individual Submissions" anchor='individual'>
<t>This section identifies opportunities to promote IPR disclosure within the IETF document lifecycle for documents that are processed outside the context of a working group (so-called "individual submissions"). In general, these opportunities are encountered during socialization, area director review, and IETF Last Call.</t>
<section title="Presenting an Internet-Draft at an IETF Meeting" anchor='individual-present'>
<t>When IETF participants wish to socialize a personal draft not intended for a working group, it is still common to request a slot on the agenda at an upcoming face-to-face meeting. These requests might be made to related working groups or area meetings, or even during plenary time. Before the community commits resources to reviewing and considering the draft, it is very reasonable for the chairs of that meeting (WG chair, AD, IESG chair, or IAB chair) to confirm that all IPR disclosures have been submitted.</t>
<t>The meeting chairs ought to request confirmation from each of the authors and listed contributors, especially if those individuals are associated with multiple organizations. Where the presentation covers a concept that has not yet been documented as an Internet-Draft, the chairs ought to at least request informal disclosure from the authors and listed contributors, as described above.</t>
</section>
<section title="AD Review" anchor='individual-review'>
<t>When considering the possibility of sponsoring an individual submission, an AD ought to confirm that all IPR disclosures have been submitted. The AD ought to require confirmation from each of the authors and listed contributors, even if those individuals are associated with the same organization. As with WG documents, a Document Shepherd Write-up is also required for AD sponsored documents, following the template at <eref target='http://www.ietf.org/iesg/template/individual-doc-writeup.html'/>. At the time of this writing, the template asks the document shepherd to answer the following question:</t>
<t>
<list style='empty'>
<t>(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.</t>
</list>
</t>
</section>
<section title="IETF Last Call" anchor='individual-lc'>
<t>As with working group documents, IETF Last Call is the mechanism used by the AD and the IESG as a whole to gauge IETF-wide consensus. It is critical that the community have easy access to all related IPR statements when considering an Internet-Draft. The current tools automatically include the URL for each IPR statement explicitly linked to the draft when the default IETF Last Call message is generated. If the AD edits this message, the links to IPR disclosure statements ought to be preserved.</t>
</section>
</section>
<section title="Conclusions" anchor='conclusions'>
<t>WG chairs and ADs are not expected to enforce IPR disclosure rules, and this document does suggest that they take on such a role. However, lack of compliance with IPR disclosure policies can have a significant impact on the Internet Standards Process. To support the efficient development of IETF standards and avoid unnecessary delays, WG chairs and ADs are encouraged to look for opportunities to promote awareness and compliance with the IETF's IPR policies. The strategies in this document promote compliance by raising the question of IPR disclosure at critical junctures in the standardization process.</t>
</section>
<section title="Security Considerations" anchor='security'>
<t>This document suggests strategies for promoting compliance with IPR disclosure rules during the IETF standards process. These procedures do not have a direct impact on the security of the Internet.</t>
</section>
<section title="IANA Considerations" anchor='iana'>
<t>This document has no actions for IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC3979'>
<front>
<title>Intellectual Property Rights in IETF Technology</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'>
<organization /></author>
<date year='2005' month='March' />
<abstract>
<t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3978, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='79' />
<seriesInfo name='RFC' value='3979' />
<format type='TXT' octets='41366' target='http://www.rfc-editor.org/rfc/rfc3979.txt' />
</reference>
<reference anchor='RFC4879'>
<front>
<title>Clarification of the Third Party Disclosure Procedure in RFC 3979</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<date year='2007' month='April' />
<abstract>
<t>This document clarifies and updates a single sentence in RFC 3979. Specifically, when third party Intellectual Property Rights (IPR) disclosures are made, the intention is that the IETF Executive Director notify the IPR holder that a third party disclosure has been filed, and to ask the IPR holder whether they have any disclosure that needs to be made, per applicable RFC 3979 rules. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
<seriesInfo name='BCP' value='79' />
<seriesInfo name='RFC' value='4879' />
<format type='TXT' octets='5570' target='http://www.rfc-editor.org/rfc/rfc4879.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC1602'>
<front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 2</title>
<author initials='C.' surname='Huitema' fullname='Christian Huitema'>
<organization>INRIA, Sophia-Antipolis</organization>
<address>
<postal>
<street>2004 Route des Lucioles</street>
<street>BP 109</street>
<city>Valbonne Cedex</city>
<region />
<code>F-06561</code>
<country>FR</country></postal>
<phone>+33 93 657715</phone>
<email>Christian.Huitema@MIRSA.INRIA.FR</email></address></author>
<author initials='P.' surname='Gross' fullname='Phill Gross'>
<organization>MCI Data Services Division</organization>
<address>
<postal>
<street>2100 Reston Parkway</street>
<street>Room 6001</street>
<city>Reston</city>
<region>VA</region>
<code>22091</code>
<country>US</country></postal>
<phone>+1 703 715 7432</phone>
<facsimile>+1 703 715 7436</facsimile>
<email>0006423401@mcimail.com</email></address></author>
<date year='1994' month='March' />
<abstract>
<t>This document is a revision of RFC 1310, which defined the official procedures for creating and documenting Internet Standards.</t>
<t>This revision (revision 2) includes the following major changes:</t>
<t>(a) The new management structure arising from the POISED Working Group is reflected. These changes were agreed to by the IETF plenary and by the IAB and IESG in November 1992 and accepted by the ISOC Board of Trustees at their December 1992 meeting.</t>
<t>(b) Prototype status is added to the non-standards track maturity levels (Section 2.4.1).</t>
<t>(c) The Intellectual Property Rights section is completely revised, in accordance with legal advice. Section 5 of this document replaces Sections 5 and 6 of RFC-1310. The new section 5 has been reviewed by legal counsel to the Internet Society.</t>
<t>(d) An appeals procedure is added (Section 3.6).</t>
<t>(e) The wording of sections 1 and 1.2 has been changed to clarify the relationships that exist between the Internet Society and the IAB, the IESG, the IETF, and the Internet Standards process.</t>
<t>(f) An Appendix B has been added, listing the contact points for the RFC editor, the IANA, the IESG, the IAB and the ISOC. The "future issues" are now listed in Appendix C.</t></abstract></front>
<seriesInfo name='RFC' value='1602' />
<format type='TXT' octets='88465' target='http://www.rfc-editor.org/rfc/rfc1602.txt' />
</reference>
<reference anchor='RFC2026'>
<front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='Scott O. Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1996' month='October' />
<abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.</t></abstract></front>
<seriesInfo name='BCP' value='9' />
<seriesInfo name='RFC' value='2026' />
<format type='TXT' octets='86731' target='http://www.rfc-editor.org/rfc/rfc2026.txt' />
</reference>
<reference anchor="RFC2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date month='March' year='1997' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC2418'>
<front>
<title abbrev='IETF Guidelines'>IETF Working Group Guidelines and Procedures</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass Ave.</street>
<street>Cambridge</street>
<country>MA</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1998' month='September' />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>
<abstract>
<t>
The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet
Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for formation
and operation of IETF working groups. It also describes the formal
relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF
participants, including WG Chairs, WG participants, and IETF Area
Directors.
</t></abstract></front>
<seriesInfo name='BCP' value='25' />
<seriesInfo name='RFC' value='2418' />
<format type='TXT' octets='62857' target='http://www.rfc-editor.org/rfc/rfc2418.txt' />
<format type='HTML' octets='77010' target='http://xml.resource.org/public/rfc/html/rfc2418.html' />
<format type='XML' octets='62422' target='http://xml.resource.org/public/rfc/xml/rfc2418.xml' />
</reference>
<reference anchor='RFC3669'>
<front>
<title>Guidelines for Working Groups on Intellectual Property Issues</title>
<author initials='S.' surname='Brim' fullname='S. Brim'>
<organization /></author>
<date year='2004' month='February' />
<abstract>
<t>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. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='3669' />
<format type='TXT' octets='40946' target='http://www.rfc-editor.org/rfc/rfc3669.txt' />
</reference>
<reference anchor='RFC4858'>
<front>
<title>Document Shepherding from Working Group Last Call to Publication</title>
<author initials='H.' surname='Levkowetz' fullname='H. Levkowetz'>
<organization /></author>
<author initials='D.' surname='Meyer' fullname='D. Meyer'>
<organization /></author>
<author initials='L.' surname='Eggert' fullname='L. Eggert'>
<organization /></author>
<author initials='A.' surname='Mankin' fullname='A. Mankin'>
<organization /></author>
<date year='2007' month='May' />
<abstract>
<t>This document describes methodologies that have been designed to improve and facilitate IETF document flow processing. It specifies a set of procedures under which a working group chair or secretary serves as the primary Document Shepherd for a document that has been submitted to the IESG for publication. Before this, the Area Director responsible for the working group has traditionally filled the shepherding role. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4858' />
<format type='TXT' octets='48572' target='http://www.rfc-editor.org/rfc/rfc4858.txt' />
</reference>
<reference anchor='RFC5741'>
<front>
<title>RFC Streams, Headers, and Boilerplates</title>
<author initials='L.' surname='Daigle' fullname='L. Daigle'>
<organization /></author>
<author initials='O.' surname='Kolkman' fullname='O. Kolkman'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2009' month='December' />
<abstract>
<t>RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5741' />
<format type='TXT' octets='32160' target='http://www.rfc-editor.org/rfc/rfc5741.txt' />
</reference>
<reference anchor='Sanctions'>
<front>
<title>Sanctions Available for Application to Violators of IETF IPR Policy</title>
<author initials='A' surname='Farrel' fullname='Adrian Farrel'>
<organization />
</author>
<author initials='P' surname='Resnick' fullname='Pete Resnick'>
<organization />
</author>
<date month='April' day='25' year='2012' />
<abstract><t>The IETF has developed and documented policies that govern the behavior of all IETF participants with respect to Intellectual Property Rights (IPR) about which they might reasonably be aware. The IETF takes conformance to these IPR policies very seriously. However, there has been some ambiguity as to what the appropriate sanctions are for the violation of these policies, and how and by whom those sanctions are to be applied. This document discusses these issues and provides a suite of potential actions that may be taken within the IETF community.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-farrresnickel-ipr-sanctions-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-farrresnickel-ipr-sanctions-05.txt' />
</reference>
</references>
<section title="Sample Messages" anchor="messages">
<t>This section provides sample messages of the kind that ADs, WG chairs, and WG secretaries can send to meeting presenters, document authors, document editors, listed contributors, and working groups during various stages of the Internet Standards Process. The messages use a hypothetical working group called the "FOO WG", hypothetical WG chairs named "Alice" and "Bob", a hypothetical author named "Nigel Throckmorton", a hypothetical AD named "Christopher", and hypothetical documents about a hypothetical technology called "wiffle"; any resemblance to actual working groups, WG chairs, ADs, or documents is strictly coincidental. The last two messages might be appropriate for sending to individuals who have requested a slot on the agenda during an IETF meeting or who have requested AD sponsorship of an individual submission.</t>
<section title="General WG Reminder" anchor="messages-general">
<t>Subject: Reminder about IETF IPR Policy</t>
<t>Dear FOO WG:</t>
<t>As FOO WG chairs, we would like to minimize or hopefully even eliminate late disclosures relating to documents under consideration within the FOO WG. Therefore you might see us send "reminder" messages in the future to authors or to the FOO WG email list as a whole, asking people whether they know of Intellectual Property Rights (IPR) relating to specific documents. In order to comply with IETF processes and avoid unnecessary delays, document authors and contributors to our discussions in the FOO WG are asked to take pay careful attention to these messages and to reply in a timely fashion.</t>
<t>Please note that these messages are only reminders of existing IETF policy, and we are all bound by that policy even in the absence of such reminder messages. Everyone who participates in the Internet Standards Process (whether by posting to IETF mailing lists, authoring documents, attending IETF meetings, or in other ways) needs to be aware of the IETF rules with regard to IPR. These rules are described in BCP79 and can be referenced through <eref target='http://www.ietf.org/ipr/policy.html'/>. In addition, online tools for filing IPR disclosures can be found at <eref target='http://www.ietf.org/ipr/file-disclosure'/>.</t>
<t>Also note that these are personal requirements applying to all IETF participants as individuals, and that these requirements also apply to all participants in the FOO WG.</t>
<t>Thanks,</t>
<t>Alice and Bob <vspace blankLines='1'/>(as FOO WG co-chairs)</t>
</section>
<section title="Reminder before WG Adoption of an Individual Internet-Draft" anchor="messages-adoption">
<t>Subject: Reminder about IPR relating to draft-throckmorton-foo-wiffle</t>
<t>Dear FOO WG, and Especially Authors and Contributors:</t>
<t>As you can see from the consensus call the WG chairs have sent out, the authors have asked for draft-throckmorton-foo-wiffle to be considered for adoption as a WG document. We would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed.</t>
<t>Are you personally aware of any IPR that applies to draft-throckmorton-foo-wiffle? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.)</t>
<t>If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor.</t>
<t>If you are on the FOO WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP79. Please do not reply unless you want to make such a voluntary disclosure.</t>
<t>Online tools for filing IPR disclosures can be found at <eref target='http://www.ietf.org/ipr/file-disclosure'/>.</t>
<t>Alice<vspace blankLines='1'/>(as FOO WG co-chair)</t>
</section>
<section title="Reminder before Working Group Last Call" anchor="messages-lastcall">
<t>Subject: Reminder about IPR relating to draft-ietf-foo-wiffle</t>
<t>Dear FOO WG:</t>
<t>The authors of draft-ietf-foo-wiffle have asked for a Working Group Last Call. Before issuing the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed.</t>
<t>Are you personally aware of any IPR that applies to draft-ietf-foo-wiffle? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.)</t>
<t>If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor.</t>
<t>If you are on the FOO WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP79. Please do not reply unless you want to make such a voluntary disclosure.</t>
<t>Online tools for filing IPR disclosures can be found at <eref target='http://www.ietf.org/ipr/file-disclosure'/>.</t>
<t>Thanks,</t>
<t>Bob</t>
<t>(as FOO WG co-chair)</t>
</section>
<section title="Reminder to Meeting Presenter" anchor="messages-presenter">
<t>Subject: IPR about draft-throckmorton-wiffle-bar</t>
<t>Dear Nigel,</t>
<t>I have received your request to give a talk about draft-throckmorton-wiffle-bar at the next IETF meeting. Before approving this request, I would like to check whether there are any claims of Intellectual Property Rights (IPR) on this document.</t>
<t>Are you aware of any IPR that applies to draft-throckmorton-wiffle-bar? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.)</t>
<t>Please reply to this email regardless of whether or not you are personally aware of any relevant IPR. I might not be able to approve your request for a slot on the agenda until I have received a reply from you and any listed contributor.</t>
<t>Online tools for filing IPR disclosures can be found at <eref target='http://www.ietf.org/ipr/file-disclosure'/>.</t>
<t>Thanks,</t>
<t>Christopher</t>
<t>(as AD)</t>
</section>
<section title="Reminder to Author of an Individual Submission before IETF Last Call" anchor="messages-individual">
<t>Subject: Reminder about IPR relating to draft-throckmorton-wiffle-bar</t>
<t>Dear Nigel,</t>
<t>Before proceeding with your request for AD sponsoring of draft-throckmorton-wiffle-bar, I would like to check whether there are any claims of Intellectual Property Rights (IPR) on the document.</t>
<t>Are you personally aware of any IPR that applies to draft-throckmorton-wiffle-bar? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 and 5378 for more details.)</t>
<t>Please reply to this email regardless of whether or not you are personally aware of any relevant IPR. I might not be able to advance this document to the next stage until I have received a reply from you and any listed contributor.</t>
<t>Online tools for filing IPR disclosures can be found at <eref target='http://www.ietf.org/ipr/file-disclosure'/>.</t>
<t>Thanks,</t>
<t>Christopher</t>
<t>(as AD)</t>
</section>
</section>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Scott Brim, Adrian Farrel, Stephen Farrell, Russ Housley, Subramanian Moonesamy, Thomas Narten, Pete Resnick, and Stephan Wenger for their feedback; and to Loa Andersson, Ross Callon, and George Swallow for drafts of some of the sample email messages.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:35:52 |