One document matched: draft-polk-ipr-disclosure-00.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-00">

  <?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</organization>
      <address>
        <postal>
          <street>1899 Wyknoop 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="2" month="August" year="2011"/>

    <abstract>
      <t>The disclosure process for intellectual property rights (IPR) in IETF stream documents is essential to the accurate development of community consensus.  However, this process is not always followed by participants in the IETF process.  Regardless of the cause or motivation, noncompliance with IPR disclosure rules can derail or delay completion of standards documents.  This document describes strategies for promoting compliance with the IPR disclosure rules.  The strategies are primarily intended for 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 IETF stream documents is essential to the accurate and efficient development of consensus by the community.  Ensuring that IETF working groups and participants have as much information as possible regarding IPR constraints, as early as possible in the process, enables the community to develop an informed consensus regarding technical proposals.  Statements to that effect appear in <xref target='RFC1602'/>, Section 5.5 Clause (B), and <xref target='RFC2026'/>, Section 10.4 Clause (B).</t>
      <t>However, IPR disclosures often do not occur at the earliest possible stage in the IETF process.  Individuals might delay disclosure through an oversight, to subvert the consensus process, or introduce delay.  Regardless of the cause or motivation, noncompliance with IPR disclosure rules can derail or delay completion of standards documents.  Disclosure of IPR after significant decisions, such as working group last call, might lead to reconsideration of those actions.  For example, a working group (WG) might change course and use a previously rejected technical proposal with less onerous limitations.  Such course corrections introduce unnecessary delays in the standardization process.</t>
      <t>This document suggests strategies for promoting compliance with the IPR disclosure rules and thereby avoiding such delays.  The strategies are primarily intended for area directors (ADs), working group chairs, and working group secretaries.</t>
      <t>The strategies are focused on promoting early disclosure by authors, since late disclosure involving authors has historically caused significant delays in the standardization process.  Many of the strategies also promote early disclosure by other contributors.</t>

      <section title="Terminology" anchor='intro-terms'>

        <t>This document relies on the definitions provided in section 1 of <xref target='RFC3979'/>.</t>
        <t>This document does not use the conformance language described in <xref target='RFC2119'/>.</t>

      </section>

    </section>

    <section title="Background" anchor='background'>

      <t>The responsibilities of contributors and IETF participants regarding IPR disclosure are documented in <xref target='RFC3979'/> and <xref target='RFC4879'/>.  These documents do not assign any further responsibilities to working group chairs and area directors, other than those imposed by their role(s) as contributor or participant.  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'/>, working group chairs are responsible for "making forward progress through a fair and open process" and area directors are responsible for "ensuring that working groups in their area produce ... timely output."  IPR disclosure at the earliest possible time is an essential feature of a "fair and open process," and late disclosure impedes timely output through recycling and appeals.</t>
      <t>To better fulfill their responsibilities in the IETF standards process, ADs and WG chairs 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, and IETF last call.  The strategies proposed in this section are primarily implemented by working group chairs. (The exceptions are strategies for IETF Last Call, which would be implemented by ADs.)  In cases where the working secretary creates meeting agendas or initiates consensus calls, the secretary might also implement these strategies.</t>
      <t>The working group process provides a number of opportunities to encourage early IPR disclosure.  The first opportunities may be presented 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 agenda time 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 chair to confirm (often via email) that all IPR disclosures have been submitted.  The chair should request confirmation from each of the authors, especially if authors are from multiple organizations.</t>
      <t>If necessary disclosures have not been submitted, the chair has a choice: insist on an informal disclosure in the presentation, or deny the agenda slot unless the IPR disclosure is submitted.  One factor in this decision could be the number of revisions that have occurred: the chair might wish to permit presentation of a -00 draft with a verbal disclosure, but not after a draft has gone through multiple cycles.</t>
      <t>In some cases, an IETF participant has not developed an Internet Draft but might still request agenda time to discuss a proposal for new draft, or a new feature for an existing working group document.  Again, it is very reasonable for the WG chair to confirm that all IPR disclosures have been submitted before approving agenda time, so that the community does not commit resources to analyzing the proposal without knowledge of IPR limitations.</t>
      <t>When a technical proposal is considered for adoption by the working group, the chair might wish to explicitly ask the WG participants if anyone is aware of IPR that is associated with this proposal.  While requiring confirmation from each working group participant is clearly impossible, silence might be interpreted as as a weak "No".</t>
      <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 chair would be less than reliable.  Even if the 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.  New participants with knowledge of IPR claims might have joined the working group.  Chairs might wish to re-confirm with each of the authors, even if the authors all work for the same organization.  Chairs might also wish to include a reminder about the importance of IPR disclosures in any Last Call message.  (Note: If IPR disclosure statements have been filed, the chair might wish to include a link in the Last Call email message to ensure the consensus call reflects this information.)</t>
      <t>Working group documents are forwarded to the appropriate Area Director after successfully completing working group Last Call.  Area directors  are encouraged determine whether the chairs took explicit action to promote disclosure of IPR.  If the chair did not take any of the actions listed above, the Area Director might choose to contact authors and other key contributors (e.g., those listed in the acknowledgements) to confirm that appropriate IPR disclosure statements have been filed.</t>
      <t>IETF Last Call is the AD's vehicle for gauging 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 Last Call message is generated.  If the AD edits this message, the links to IPR disclosure statements should be preserved.</t>

    </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 not processed in a working group.  In general, these opportunities are encountered during socialization, area director review, and IETF last call.</t>
      <t>When IETF participants wish to socialize a personal draft not intended for a working group, it is still common to request agenda time at an upcoming face-to-face meeting.  These requests might be made to related working groups, area meetings, or even plenary time.  Before the community commits resources to reviewing and considering the draft, it is very reasonable for the chair of that meeting (WG chair, AD, IESG chair or IAB chair) to confirm that all IPR disclosures have been submitted.</t>
      <t>The meeting chair should request confirmation from each of the authors, especially if authors are from multiple organizations.  Where the presentation covers a concept that has not been documented as an Internet-Draft, the chair should request confirmation from any co-authors and from contributors acknowledged in the slide deck.</t>
      <t>When considering the possibility of sponsoring an Internet-Draft, an AD should also confirm that all IPR disclosures have been submitted.  The AD should require confirmation from each of the authors, even if authors are from the same organization.</t>
      <t>As with working group documents, IETF Last Call is the AD's vehicle for gauging 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 Last Call message is generated.  If the AD edits this message, the links to IPR disclosure statements should be preserved.</t>

    </section>

    <section title="Conclusions" anchor='conclusions'>
    
      <t>WG chairs and ADs are not expected to enforce IPR disclosure rules.  This document is not suggesting that they take on such a role.  However, compliance with IPR disclosure policies can significantly impact their effectiveness.  To support the efficient development of IETF standards and avoid unnecessary delays, chairs and ADs should 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>

    </references>

  </back>

</rfc>