idnits 2.17.1 draft-bormann-t2trg-rel-impl-02.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (27 September 2020) is 1301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-bormann-t2trg-rel-impl-01 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-25 -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational 27 September 2020 5 Expires: 31 March 2021 7 impl-info: A link relation type for disclosing implementation 8 information 9 draft-bormann-t2trg-rel-impl-02 11 Abstract 13 For debugging, it is often helpful to have information about the 14 implementation of a peer. The present specification defines a link 15 relation type, "impl-info", that can be used to convey such 16 information via self-description, such as in the "/.well-known/core" 17 resource. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 31 March 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 2 54 3. Security considerations . . . . . . . . . . . . . . . . . . . 2 55 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. Normative References . . . . . . . . . . . . . . . . . . 3 57 4.2. Informative References . . . . . . . . . . . . . . . . . 3 58 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 4 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1. Introduction 63 When debugging an interoperability problem, it is often helpful to 64 have information about the implementation version of a peer. To 65 enable the disclosure of such information, HTTP defines header fields 66 such as Server and User-Agent [RFC7231]. 68 In CoAP [RFC7252], it is rarely appropriate to send information of 69 this kind in every request or response. Instead, the present 70 specification defines a link relation type, "impl-info", that can be 71 used to convey this information via the self-description capabilities 72 of the "/.well-known/core" resource [RFC6690] and the CoRE resource 73 directory [I-D.ietf-core-resource-directory]. 75 2. IANA Considerations 77 This specification requests the registration of the link relation 78 type "impl-info". 80 The registration template as per [RFC8288] follows. 82 * _Relation Name_: "impl-info" 84 * _Description_: Refers to implementation information that may be 85 helpful in diagnosing technical problems with the implementation 86 of the context, such as lists of components and their 87 implementation versions. 89 * _Reference_: [THIS] 91 3. Security considerations 93 The security considerations listed in Section 9.6 of [RFC7231] and 94 the sections referenced there apply. 96 The security considerations listed in Section 11.3 of [RFC7252] 97 apply. As adding another link to "/.well-known/core" does increase 98 the size of a response to a GET request for that resource, the 99 mitigation mentioned in that section to limit the amplification 100 factor becomes even more important. 102 Disclosing information about an implementation can make it easier for 103 an attacker to select an attack, or to build automated tools that 104 search for promising victims. Fingerprinting techniques can provide 105 information to attackers that is usable in the same way, so adding 106 information via self-description may or may not actually exacerbate 107 this problem. 109 4. References 111 4.1. Normative References 113 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 114 DOI 10.17487/RFC8288, October 2017, 115 . 117 [THIS] Bormann, C., "impl-info: A link relation type for 118 disclosing implementation information", Work in Progress, 119 Internet-Draft, draft-bormann-t2trg-rel-impl-01, 27 March 120 2020, . 123 4.2. Informative References 125 [I-D.ietf-core-resource-directory] 126 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 127 Amsuess, "CoRE Resource Directory", Work in Progress, 128 Internet-Draft, draft-ietf-core-resource-directory-25, 13 129 July 2020, . 132 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 133 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 134 . 136 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 137 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 138 DOI 10.17487/RFC7231, June 2014, 139 . 141 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 142 Application Protocol (CoAP)", RFC 7252, 143 DOI 10.17487/RFC7252, June 2014, 144 . 146 Acknowledgements 148 The need for implementation information in the CoRE resource 149 directory has been identified by Peter van der Stok. Discussions 150 with Peter and with Christian Amsüss led to the present proposal of 151 employing self-description for this purpose. 153 Author's Address 155 Carsten Bormann 156 Universität Bremen TZI 157 Postfach 330440 158 D-28359 Bremen 159 Germany 161 Phone: +49-421-218-63921 162 Email: cabo@tzi.org