idnits 2.17.1 draft-lear-opsawg-ol-01.txt: -(5): 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 2 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 May 2021) is 1058 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SPDX' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems 4 Updates: 8520 (if approved) C. Bormann 5 Intended status: Standards Track Universität Bremen TZI 6 Expires: 28 November 2021 27 May 2021 8 Ownership and licensing statements in YANG 9 draft-lear-opsawg-ol-01 11 Abstract 13 This memo provides for an extension to RFC 8520 that allows MUD file 14 authors to specify ownership and licensing of MUD files themselves. 15 This memo updates RFC 8520. However, it can also be used for 16 purposes outside of MUD, and the grouping is structured as such. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 28 November 2021. 35 Copyright Notice 37 Copyright (c) 2021 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. The owner-license extension and model . . . . . . . . . . . . 3 53 3. The YANG schema for ownership and licensing . . . . . . . . . 3 54 4. Extension for MUD . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 7.1. MUD Extension . . . . . . . . . . . . . . . . . . . . . . 6 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 60 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 7 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 [RFC8520] Manufacturer Usage Descriptions (MUD) can be used to 66 describe devices and their requirements to the network 67 infrastructure. The original version of the specification does not 68 provide for a means to specify ownership and licensing of the MUD 69 file itself. This can hinder those wishing to use, modify, or adapt 70 MUD files for the purpose of offering them, when the manufacturer is 71 not involved. 73 * *Issue*: Should this be an owner or an originator? 75 To avoid any confusion, we define an extension that allows for 76 specifying of owners and licensing terms for MUD files. 78 Those generating MUD files SHOULD use this extension, and thus this 79 extension updates RFC 8520. 81 There are two ways to specify a license: a URL pointing to the 82 license itself or an SPDX tag [SPDX]. If an SPDX tag is supplied 83 consumers MUST interpret that tag through its meaning as specified by 84 [SPDX]. 86 * *Issue*: Should we simply say that a URI contains a colon and SPDX 87 license identifier doesn't? 89 This grouping may be used for other YANG models that reside as static 90 objects. 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 96 capitals, as shown here. 98 2. The owner-license extension and model 100 Because the model is primarily motivated by MUD, and based on the way 101 that YANG trees are formed, the model appears as an augmentation for 102 MUD. 104 module: ietf-ol 106 augment /mud:mud: 107 +--rw ol 108 +--rw owners* string 109 +--rw (license-type)? 110 +--:(spdx-lt) 111 | +--rw spdx-tag? string 112 +--:(url) 113 +--rw license-info? inet:uri 115 * *Issue*: Should different owners possibly have their own license 116 types? (Logical and, derived works.) 118 * *Issue*: Should a single owner possibly have multiple license 119 types? (Logical or, multi-licensing.) 121 3. The YANG schema for ownership and licensing 123 The following grouping and augmentation are proposed. 125 126 file "ietf-ol@2021-05-21.yang" 127 module ietf-ol { 128 yang-version 1.1; 129 namespace "urn:ietf:params:xml:ns:yang:ietf-ol"; 130 prefix ol; 132 import ietf-inet-types { 133 prefix inet; 134 } 136 import ietf-mud { 137 prefix mud; 138 } 140 organization 141 "IETF OPSAWG (Ops Area) Working Group"; 142 contact 143 "WG 144 Web: http://tools.ietf.org/wg/opsawg/ 145 WG List: opsawg@ietf.org 146 Author: Eliot Lear lear@cisco.com 147 Author: Carsten Bormann "; 148 description 149 "This YANG module to indicate ownership and licensing. 151 Copyright (c) 2021 IETF Trust and the persons identified as 152 authors of the code. All rights reserved. 154 Redistribution and use in source and binary forms, with or 155 without modification, is permitted pursuant to, and subject to 156 the license terms contained in, the Simplified BSD License set 157 forth in Section 4.c of the IETF Trust's Legal Provisions 158 Relating to IETF Documents 159 (https://trustee.ietf.org/license-info). 161 This version of this YANG module is part of RFC XXXX 162 (https://www.rfc-editor.org/info/rfcXXXX); 163 see the RFC itself for full legal notices. 165 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 166 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 167 'MAY', and 'OPTIONAL' in this document are to be interpreted as 168 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 169 they appear in all capitals, as shown here. "; 171 revision 2021-05-21 { 172 description 173 "Initial proposed standard."; 174 reference 175 "RFC XXXX: Extension for ownership and licensing"; 176 } 178 grouping ol-extension { 179 description 180 "OL extension grouping"; 181 container ol { 182 description 183 "container relating to ownership and licensing."; 184 leaf-list owners { 185 type string; 186 description 187 "A list of owners, may be in the form of a copyright 188 Example: Copyright (c) Jane Smith. All rights Reserved."; 189 } 190 choice license-type { 191 description "Either choose a standard license type or point 192 to one of your own."; 194 case spdx-lt { 195 leaf spdx-tag { 196 type string; 197 description "SPDX License Identifier, as indicated at 198 https://spdx.org/licenses/"; 199 } 200 } 201 case url { 202 leaf license-info { 203 type inet:uri; 204 description "A URL pointing to licensing information."; 205 } 206 } 207 } 208 } 209 } 211 augment "/mud:mud" { 212 description 213 "Add extension for Ownership and licensing."; 214 uses ol-extension; 215 } 216 } 217 219 4. Extension for MUD 221 MUD files using this extension MUST include "ol" in the extensions 222 array, as specified by [RFC8520]. 224 5. Example 226 In this example, the Frobmaster company is using the 0BSD SPDX tag to 227 indicate a relatively open license. The "ol" extension and container 228 are present. There is a single owner listed. 230 { 231 "ietf-mud:mud": { 232 "mud-version": 1, 233 "extensions": [ 234 "ol" 235 ], 236 "ol": { 237 "owners": [ 238 "Copyright (c) FrobMaster 2021. All Rights Reserved" 239 ], 240 "spdx-tag": "0BSD" 241 }, 242 "mud-url": "https://frobs.example.com/mud/Frob.json", 243 "mud-signature": "https://frobs.example.com/mud/Frob.p7s", 244 "last-update": "2021-05-24T11:26:04+00:00", 245 "cache-validity": 48, 246 "is-supported": true, 247 "systeminfo": "This device helps produce frobs", 248 "mfg-name": "FrobMaster", 249 "documentation": "https://frobs.example.com/doc", 250 "model-name": "Frobinator" 251 } 252 } 254 * *Task*: need Makefile for validating this against MUD. (Probably 255 put this into a separate file, too.) 257 * *Issue*: Should we give an example for usage outside yang? 259 6. Security Considerations 261 No security considerations have been identified. 263 * *Issue*: Should we maybe point out any specific seccons of 8520? 265 7. IANA Considerations 267 7.1. MUD Extension 269 The IANA is requested to add "ol" to the MUD extensions registry as 270 follows: 272 Extension Name: ol 273 Standard reference: This document 275 8. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 283 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 284 May 2017, . 286 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 287 Description Specification", RFC 8520, 288 DOI 10.17487/RFC8520, March 2019, 289 . 291 [SPDX] The Linux Foundation, "SPDX Specification 2.1", 2016. 293 Appendix A. Changes from Earlier Versions 295 Draft -01: * Add some issues * correct spacing 297 Draft -00: 299 * Initial revision 301 Authors' Addresses 303 Eliot Lear 304 Cisco Systems 305 Richtistrasse 7 306 CH-8304 Wallisellen 307 Switzerland 309 Phone: +41 44 878 9200 310 Email: lear@cisco.com 312 Carsten Bormann 313 Universität Bremen TZI 314 Postfach 330440 315 D-28359 Bremen 316 Germany 318 Email: cabo@tzi.org