idnits 2.17.1 draft-ietf-ipr-trademarks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 153. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 164. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The abstract seems to indicate that this document updates RFC3667, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC3668, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2005) is 7012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3667' is mentioned on line 45, but not defined ** Obsolete undefined reference: RFC 3667 (Obsoleted by RFC 3978) == Missing Reference: 'RFC3668' is mentioned on line 49, but not defined ** Obsolete undefined reference: RFC 3668 (Obsoleted by RFC 3979) == Unused Reference: 'RFC 3667' is defined on line 108, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Bradner 3 Internet-Draft Harvard University 4 Editor 5 January 2005 7 Indication of Trademarks in IETF Documents 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 27, 2005. 36 Abstract 37 People writing IETF documents sometimes must use trademarked terms. 38 This document clarifies how document authors can indicate that a term 39 is trademarked. This document updates RFC 3667 and 3668. 41 Copyright Notice 42 Copyright (C) The Internet Society. (2005) 44 1. Introduction 45 Section 3.6 of RFC 3667 [RFC3667] says that contributors "who claim 46 trademark rights in terms used in their IETF contributions are 47 requested to state specifically what conditions apply to implementers 48 of the technology relative to the use of such trademarks." 49 Section 11 of RFC 3668 [RFC3668] says that "IETF and RFC Editor 50 documents must not contain any mention of specific IPR." 52 But neither RFC 3667 or RFC 3668 address the question of marking such 53 terms in IETF contributions to indicate that trademark rights have 54 been claimed, nor do they address the question of other text to 55 indicate who is making the claim of trademark rights. 57 The lack of direction in RFC 3667 and RFC 3668 on these questions led 58 to considerable discussion on the IETF and IPR Working Group mailing 59 lists. This memo answers these questions. 61 2. Marking terms to indicate a claim to trademark or service mark 62 rights 64 A contributor may indicate a registered trademark or service mark by 65 appending the three characters (R) to the term or phrase. A 66 contributor may indicate that they claim, or that they acknowledge, a 67 claim to an unregistered trademark on a specific term or phrase by 68 appending the four characters (TM) to the term or phrase. A 69 contributor may indicate that they claim, or that they acknowledge, a 70 claim to an unregistered service mark on a specific term or phrase by 71 appending the four characters (SM) to the term or phrase. Such a 72 notice is optional when you are using the mark in a manner that is 73 not in connection with the sale or promotion of a product or service, 74 for example in just referencing a technology in a RFC. 76 The markings described in this document are not intended to say which 77 jurisdiction the trademarks or service marks are filed in. The 78 markings described here just assert that one such mark exists in some 79 jurisdiction. 81 Contributors should be careful not to use any of these designations 82 improperly, as such would be considered a violation of IETF policies 83 and could, in some cases, also be prohibited by applicable law. 85 3. No IPR disclosures in IETF Documents 87 To conform to the requirements of RFC 3668, the contribution must not 88 include a statement such as "Foo (TM) is a trademark of BarrCo." If a 89 contributor wants to make such a statement he or she should follow 90 Section 3.6 of RFC 3667 which says any "statements should be 91 submitted in the same way as is done for other intellectual property 92 claims. (See [RFC 3668] Section 6.)" 94 Statements about who claims a particular trademark or service mark 95 are generally not needed but may be helpful if the contributor is 96 claiming a generally unknown mark themselves. If no statement has 97 been filed with the IETF about a term or phrase that is marked in a 98 contribution as a trademark or service mark it is reasonable to 99 assume that references to the term or phrase in product text, 100 documentation and advertising material is permitted but that using 101 the term or phrase as the name of a product requires permission from 102 the holder of the mark. 104 4. References 106 4.1. Normative References 108 [RFC 3667] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, 109 RFC 3667, February 2004. 111 [RFC 3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 112 Technology", BCP 79, RFC 3668, February 2004. 114 5. Acknowledgements 116 The editor would like to acknowledge the legal advice on this topic 117 provided by Michael Bevilacqua and Jorge Contreras of Wilmer, Cutler, 118 Pickering, Hale and Dorr. 120 12. Editor's Address 122 Scott Bradner 123 Harvard University 124 29 Oxford St. 125 Cambridge MA, 02138 127 Phone: +1 617 495 3864 128 EMail: sob@harvard.edu 130 13. Full copyright statement 132 Copyright (C) The Internet Society (2004). This document is subject 133 to the rights, licenses and restrictions contained in BCP 78 and 134 except as set forth therein, the authors retain all their rights. 136 This document and the information contained herein are provided on an 137 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 138 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 139 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 140 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 141 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 142 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 144 Intellectual Property 146 The IETF takes no position regarding the validity or scope of any 147 Intellectual Property Rights or other rights that might be claimed to 148 pertain to the implementation or use of the technology described in 149 this document or the extent to which any license under such rights 150 might or might not be available; nor does it represent that it has 151 made any independent effort to identify any such rights. Information 152 on the procedures with respect to rights in RFC documents can be 153 found in BCP 78 and BCP 79. 155 Copies of IPR disclosures made to the IETF Secretariat and any 156 assurances of licenses to be made available, or the result of an 157 attempt made to obtain a general license or permission for the use of 158 such proprietary rights by implementers or users of this 159 specification can be obtained from the IETF on-line IPR repository at 160 http://www.ietf.org/ipr. The IETF invites any interested party to 161 bring to its attention any copyrights, patents or patent 162 applications, or other proprietary rights that may cover technology 163 that may be required to implement this standard. Please address the 164 information to the IETF at ietf-ipr@ietf.org. 166 Acknowledgement 168 Funding for the RFC Editor function is currently provided by the 169 Internet Society.