RFC 6702

Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules

πŸ“… published August 2012, from ietf

RFC 6702: Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules πŸŽ€

Okay bestie, this one is a total gem πŸ’– It's RFC 6702, titled Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules, and it dropped in August 2012. The authors are T. Polk from NIST and P. Saint-Andre from Cisco Systems, Inc. It's classed as Informational, which means it's advice and not a Standards Track spec πŸ’… The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's flying solo ✨


Abstract

Okay so the whole point is that IPR disclosure in documents made within the IETF stream is essential for building accurate community consensus 🧚 The catch is that people don't always do it, and noncompliance can delay or even derail IETF specs, no matter why it happens 😭 This doc shares strategies for promoting compliance with the IPR disclosure rules, mostly for area directors, working group chairs, and working group secretaries 🫢

Status of This Memo

This doc is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🌸

It's a product of the IETF and represents IETF community consensus. It got public review and was approved for publication by the IESG. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for that πŸ‘€

For the current status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc6702 πŸ¦‹

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved πŸ’œ

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you'll find at http://trustee.ietf.org/license-info as in effect on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions πŸ™ˆ Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License πŸ“

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
   2. Background ......................................................4
   3. Strategies for Working Group Documents ..........................5
      3.1. Presenting an Internet-Draft at an IETF Meeting ............5
      3.2. Requesting WG Adoption .....................................6
      3.3. Requesting WG Last Call ....................................6
      3.4. AD Review ..................................................7
      3.5. IETF Last Call .............................................7
   4. Strategies for Individual Submissions ...........................8
      4.1. Presenting an Internet-Draft at an IETF Meeting ............8
      4.2. AD Review ..................................................8
      4.3. IETF Last Call .............................................9
   5. A Note about Preliminary Disclosures ............................9
   6. Conclusions .....................................................9
   7. Security Considerations .........................................9
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10
   Appendix A. Sample Messages .......................................11
     A.1. General WG Reminder ........................................11
     A.2. Reminder to Meeting Presenter ..............................12
     A.3. Reminder before WG Adoption of an Individual
          Internet-Draft .............................................13
     A.4. Reminder before Working Group Last Call ....................14
     A.5. Reminder to Authors and Listed Contributors of a
          Working Group Document before IETF Last Call ...............15
     A.6. Reminder to Author of an Individual Submission before
          IETF Last Call .............................................15
   Appendix B. Acknowledgements ......................................16

1. Introduction ✨

Okay so the IPR disclosure process for documents in the IETF stream [RFC5741] is essential for building consensus that's both efficient and accurate 🌈 Specifically, the more info working groups and participants have about IPR constraints, and the earlier they get it, the more likely the community can form an informed consensus on technical proposals πŸ’… The second and third revisions of the Internet Standards Process both say this, see [RFC1602], Section 5.5, Clause (B) and [RFC2026], Section 10.4, Clause (B) πŸŽ€

Sometimes though, IPR disclosures don't happen at the earliest possible stage. People have lots of reasons for that, like a simple oversight, wanting to introduce delay, or trying to derail the emergence of consensus πŸ™ƒ

Whatever the reason, noncompliance can delay or even derail IETF specs 😭 Disclosing IPR after big decisions, like Working Group Last Call (WGLC), might lead to those decisions getting reconsidered. For example, a WG might change course and pick up a previously rejected technical proposal that has less onerous licensing requirements. These "course corrections" cause needless delays in standardization πŸ’€

So this doc suggests strategies for promoting compliance with the IETF's IPR disclosure rules to avoid those delays πŸ¦‹ They're mainly for area directors (ADs), WG chairs, and WG secretaries 🧚

The strategies focus on getting document authors to disclose early, because late disclosure involving authors has historically caused big delays in standardization. Plenty of these strategies also encourage early disclosure from other IETF contributors 🫢

Even if ADs, WG chairs, and WG secretaries skip these strategies, IETF contributors are still bound by the BCP 79 rules (see [RFC3979] and [RFC4879]) and the BCP 78 rules (see [RFC5378]) πŸ”₯ This doc doesn't change those rules, and it doesn't normatively extend them either. It just offers suggestions to help ADs, WG chairs, and WG secretaries πŸ’œ

Also, this doc isn't claiming to define best current practices. It suggests strategies that ADs, WG chairs, and WG secretaries might find useful. With enough use and smart tweaks based on experience, these strategies might one day become the basis for documenting best current practices 🌸

This doc doesn't cover the parallel but important question of what the IETF itself can do when its IPR policy isn't followed. That's discussed in [RFC6701], so go check it out πŸ‘€

Last thing: the Internet Research Task Force (IRTF) currently follows the same IPR disclosure rules as the IETF (see http://irtf.org/ipr). So these strategies might also be useful for IRTF research group chairs 🌈

1.1. Terminology

This doc relies on the definitions in Section 1 of [RFC3979] πŸ“–

A "formal disclosure" is an IPR disclosure statement that's officially submitted through the IPR disclosure tools at http://www.ietf.org/ipr/file-disclosure, or by sending a message to ietf-ipr@ietf.org πŸ’Œ An "informal disclosure" is a statement made in a less official way, like out loud during a presentation, written in presentation materials, or emailed to the relevant discussion list before a presentation πŸ“

Since this doc is purely informational, it intentionally doesn't use the conformance language described in [RFC2119] πŸ™ˆ

2. Background 🌷

IPR disclosure responsibilities for IETF contributors are documented in [RFC3979] and [RFC4879]. Those docs don't give ADs, WG chairs, or WG secretaries any extra responsibilities beyond the ones they already have as contributors or participants πŸ’… Still, late IPR disclosure directly affects how well working groups, WG chairs, and ADs can do their jobs 😭

According to [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." πŸ‘‘ Also, WG chairs can appoint one or more WG secretaries to help run the working group day to day (see [RFC2418]), so some of the actions in this doc might end up being done by WG secretaries 🫢

Disclosing IPR as early as possible is a key part of a "fair and open process," and late disclosure can slow down timely output. It can make the WG revisit earlier decisions, needlessly revise technical specs, and even face appeals 😱 To do their jobs well in the IETF Standards Process, ADs, WG chairs, and WG secretaries might want to use strategies that encourage early disclosure, like the ones in this doc, while staying consistent with the responsibilities set out in [RFC3979] and [RFC4879] ✨

3. Strategies for Working Group Documents 🧁

Building on the framework in [RFC3669], this section points out chances to promote IPR disclosure during the lifecycle of IETF working group documents πŸ¦‹ These chances usually come up during initial public discussion, WG adoption, WGLC, and IETF Last Call. WG chairs might also want to make WG participants more aware of why IPR disclosure matters in general, like with the sample message in Appendix A.1 πŸ’œ

The strategies in this section are mainly carried out by WG chairs. (The exceptions are the strategies for IETF Last Call, which ADs would carry out.) If a WG secretary creates meeting agendas or starts consensus calls, the secretary might also carry out these strategies πŸŽ€


(Part 1 ends here, bestie. Part 2 picks up with Section 3.1 and the goodies that follow πŸ’–)

3.1. Presenting an Internet-Draft at an IETF Meeting ✨

okay so this is where the IPR conversation gets real 🫢 the very first moment to nudge people toward early IPR disclosure can happen even before a technical proposal is a working group document. wild, right?

say someone wants to get public discussion going on their personal draft, in hopes it gets adopted by a working group someday. a super common move is to ask for an agenda slot at an upcoming face-to-face meeting. and before the community spends its time reviewing the draft, it's totally reasonable for the WG chairs to double-check (usually over email) that all the IPR disclosures are in πŸ’… the chairs really ought to ask each author and listed contributor for confirmation, especially if those people are tied to multiple organizations. main character chair behavior πŸ‘‘

now, if the disclosures aren't in yet, the chairs have a choice πŸŽ€ they can deny the agenda slot unless formal IPR disclosure statements get submitted, or they can allow informal disclosure. one thing that might factor in is how many revisions the draft has gone through: the chairs might be fine letting a -00 draft present with informal disclosure, but not once it's been through multiple revision cycles πŸ¦‹ if informal disclosure is allowed, the chairs ought to make sure it's written down in the minutes, and ought to encourage formal disclosure statements after the meeting. literally the paper trail is everything 🌸

sometimes a participant hasn't submitted an Internet-Draft at all, but still wants an agenda slot to talk about a proposal for a new draft, or a new feature for an existing working group document. same deal here: it's very reasonable for the WG chairs to confirm, before approving the slot, that all IPR claims have been disclosed. this will likely be the informal kind we just talked about, since the participant hasn't made a Contribution as defined by the Internet Standards Process [RFC3979] yet 🧚

a sample message for this stage is in Appendix A.2 πŸ’œ

3.2. Requesting WG Adoption 🌈

when a technical proposal is up for adoption by a working group, the chairs get another chance to confirm (or reconfirm) IPR compliance with the authors and listed contributors πŸ”₯ the chairs might also want to explicitly ask WG participants whether anyone knows of IPR tied to the proposal. ask the room, bestie πŸ™ˆ

a sample message for this stage is in Appendix A.3 πŸ“

3.3. Requesting WG Last Call πŸ’–

Working Group Last Call is a big milestone, because it's the final check on consensus within the working group 😭 if IPR disclosure statements haven't been submitted, the chairs' read on consensus is less reliable, since it's built on incomplete assumptions. and even if the earlier procedures were followed to promote disclosure, features can evolve in ways that bring up new IPR concerns ✨ new participants who know about IPR claims may also have shown up in the working group by now.

so the WG chairs might want to reconfirm with each author and listed contributor that the right IPR disclosure statements have been filed, even if they all work for the same organization πŸ’… the chairs might also want to include a reminder about how important IPR disclosures are in any WGLC message sent to the working group. (psst, side note: if disclosure statements have been filed, the chairs might want to include a link in the WGLC message so the consensus call reflects that info πŸ¦‹)

a sample message for this stage is in Appendix A.4 🫢

3.4. AD Review πŸ‘‘

after WGLC wraps up successfully, the working group document gets forwarded to the appropriate area director for AD review, with a request that the AD process it for publication as an RFC πŸŽ€ that publication request comes with a Document Shepherd Write-Up, as required by [RFC4858], using the template found at:

<http://www.ietf.org/iesg/template/doc-writeup.html>

as of this writing, the template asks the document shepherd this question:

(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.

shepherds ought to be asking authors that question directly πŸ’… the AD can also ask the WG chairs whether they took explicit action to promote IPR disclosure.

if the answer to the write-up question isn't favorable, or the chairs didn't take any of the actions listed above, the AD might decide to contact the authors and listed contributors to confirm that the right IPR disclosure statements have been filed before the document moves forward in the publication process 😭

a sample message for this stage is in Appendix A.5 🌸

3.5. IETF Last Call 🌈

IETF Last Call is the mechanism the AD and the IESG as a whole use to gauge IETF-wide consensus πŸ”₯ it is critical that the community can easily access 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 gets generated πŸ’– if the AD edits that message, the links to IPR disclosure statements ought to be preserved, no excuses πŸ™ˆ

4. Strategies for Individual Submissions ✨

this section covers opportunities to promote IPR disclosure for documents processed outside a working group (the so-called "individual submissions") πŸ¦‹ generally, these opportunities show up during initial public discussion, area director review, and IETF Last Call 🧚

4.1. Presenting an Internet-Draft at an IETF Meeting πŸ’œ

when IETF participants want to promote public discussion of a personal draft that's not meant for a working group, it's still common to request an agenda slot at an upcoming face-to-face meeting πŸŽ€ those requests might go to related working groups or area meetings, or even get raised during plenary time. before the community commits resources to reviewing the draft, it's 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 πŸ’…

the meeting chairs ought to request confirmation from each author and listed contributor, especially if those people are associated with multiple organizations 🫢 where the presentation covers a concept that hasn't been documented as an Internet-Draft yet, the chairs ought to at least request informal disclosure from the authors and listed contributors, as described above 🌸

a sample message for this stage is in Appendix A.2 πŸ“

4.2. AD Review πŸ”₯

when an AD is considering sponsoring an individual submission, they ought to confirm that all IPR disclosures have been submitted πŸ‘‘ the AD ought to require confirmation from each author and listed contributor, even if they're all with the same organization πŸ’… just like WG documents, a Document Shepherd Write-Up is also required for AD-sponsored documents, following the template at:

<http://www.ietf.org/iesg/template/individual-doc-writeup.html>

as of this writing, the template asks the document shepherd this question:

(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.

a sample message for this stage is in Appendix A.6 πŸ’–

4.3. IETF Last Call 🌈

same as with working group documents, IETF Last Call is the mechanism the AD and the IESG as a whole use to gauge IETF-wide consensus πŸ¦‹ it is critical that the community can easily access 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 πŸ’œ

5. A Note about Preliminary Disclosures πŸŽ€

okay this one's a little plot twist 😭 early disclosures aren't necessarily complete disclosures. [RFC3979] can be read as encouraging "preliminary disclosure" (e.g., when a new patent application is made), but a preliminary disclosure might not get updated as new info comes in later in the standardization process (e.g., when a patent is actually granted) πŸ’…

to help stop early IPR disclosures from going stale or incomplete, at important junctures in the standardization process (e.g., at working group adoption, before Working Group Last Call, and before IETF Last Call), WG chairs and ADs are encouraged to request that the Executive Director of the IETF contact those who submitted early IPR disclosures about updating them 🫢

6. Conclusions 🌸

WG chairs and ADs are not expected to enforce IPR disclosure rules, and this document does not suggest they take on that role πŸ™ˆ however, lack of compliance with IPR disclosure policies can have a significant impact on the Internet Standards Process 😭 to support 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 ✨

7. Security Considerations πŸ’€

okay, the security section is short but it's giving "no drama 🫢" 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 πŸ”₯

8. References πŸ’œ

8.1. Normative References 🌈

[RFC3979]  Bradner, S., Ed., "Intellectual Property Rights in IETF
           Technology", BCP 79, RFC 3979, March 2005.

[RFC4879]  Narten, T., "Clarification of the Third Party Disclosure
           Procedure in RFC 3979", BCP 79, RFC 4879, April 2007.

8.2. Informative References ✨

Okay, so these are the bonus reads. They're not required to implement anything, but they're the background you'll want if you're curious about where all of this came from. πŸ“š

  • [RFC1602] Internet Architecture Board and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994.
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.
  • [RFC3669] Brim, S., "Guidelines for Working Groups on Intellectual Property Issues", RFC 3669, February 2004.
  • [RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, "Document Shepherding from Working Group Last Call to Publication", RFC 4858, May 2007.
  • [RFC5378] Bradner, S., Ed., and J. Contreras, Ed., "Rights Contributors Provide to the IETF Trust", BCP 78, RFC 5378, November 2008.
  • [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
  • [RFC6701] Farrel, A. and P. Resnick, "Sanctions Available for Application to Violators of IETF IPR Policy", RFC 6701, August 2012.

Appendix A. Sample Messages πŸ’Œ

Here's where it gets fun. This appendix has sample messages that ADs, WG chairs, and WG secretaries can send to meeting presenters, document authors, document editors, listed contributors, and working groups at different stages of the Internet Standards Process. Everyone in these emails is totally made up: the "FOO WG", the chairs "Alice" and "Bob", the author "Nigel Throckmorton", the AD "Christopher", and the "wiffle" technology. Any resemblance to real people or groups is pure coincidence πŸ™ˆ. The last two messages are the ones to send to folks who asked for an agenda slot at an IETF meeting or asked for AD sponsorship of an individual submission.

A.1. General WG Reminder πŸ“£

Subject: Reminder about IETF IPR Policy

Dear FOO WG:

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 pay
careful attention to these messages and to reply in a timely fashion.

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 BCP 79 and can be referenced through
<http://www.ietf.org/ipr/policy.html>.  In addition, online tools for
filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.  Finally, existing
disclosures can be searched online at
<https://datatracker.ietf.org/ipr/search/>.

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.

Thanks,

Alice and Bob

(as FOO WG co-chairs)

A.2. Reminder to Meeting Presenter 🎀

Subject: IPR about draft-throckmorton-wiffle-bar

Dear Nigel,

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.

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.)

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.

Online tools for filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.

Thanks,

Alice

(as FOO WG co-chair)

A.3. Reminder before WG Adoption of an Individual Internet-Draft 🌱

Subject: Reminder about IPR relating to draft-throckmorton-foo-wiffle

Dear FOO WG, and Especially Authors and Contributors:

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.

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.)

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.

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 BCP 79.  Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.

Thanks,

Alice

(as FOO WG co-chair)

A.4. Reminder before Working Group Last Call πŸ—³οΈ

Subject: Reminder about IPR relating to draft-ietf-foo-wiffle

Dear FOO WG:

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.

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.)

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.

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 BCP 79.  Please do not reply
unless you want to make such a voluntary disclosure.

Online tools for filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.

Thanks,

Bob

(as FOO WG co-chair)

A.5. Reminder to Authors and Listed Contributors of a Working Group Document before IETF Last Call πŸ””

Subject: Reminder about IPR relating to draft-ietf-foo-wiffle

Dear Authors and Contributors (Chairs and Shepherd cc'd),

Before proceeding with your request to issue an IETF Last Call on
draft-ietf-foo-wiffle, I would like to check whether there are any
claims of Intellectual Property Rights (IPR) on the document.

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.)

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.

Online tools for filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.

Thanks,

Christopher

(as AD)

A.6. Reminder to Author of an Individual Submission before IETF Last Call πŸŽ€

Subject: Reminder about IPR relating to draft-throckmorton-wiffle-bar

Dear Nigel,

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.

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.)
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.

Online tools for filing IPR disclosures can be found at
<http://www.ietf.org/ipr/file-disclosure>.

Thanks,

Christopher

(as AD)

Appendix B. Acknowledgements πŸ’–

Big thank-yous to everyone who helped make this happen. Thanks to Scott Brim, Stewart Bryant, Benoit Claise, Adrian Farrel, Stephen Farrell, Russ Housley, Subramanian Moonesamy, Thomas Narten, Pete Resnick, and Stephan Wenger for their feedback 🫢. Thanks also to Loa Andersson, Ross Callon, and George Swallow for drafts of some of the sample email messages, and to Stephen Farrell for shepherding the document. πŸ‘‘

Authors' Addresses πŸ–‹οΈ

Tim Polk
National Institute of Standards and Technology
100 Bureau Drive, MS 8930
Gaithersburg, MD  20899-8930
USA

EMail: tim.polk@nist.gov


Peter Saint-Andre
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO  80202
USA

Phone: +1-303-308-3282
EMail: psaintan@cisco.com
πŸ“¦ where this page comes from