idnits 2.17.1 draft-groves-core-rfc6690up-01.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6690]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 19, 2017) is 2561 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) -- Looks like a reference, but probably isn't: '1' on line 319 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- No information found for draft-candidate-specifications - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Groves 3 Internet-Draft 4 Intended status: Standards Track W. Yang 5 Expires: October 21, 2017 Huawei 6 April 19, 2017 8 Addition of organisation prefix to RFC6690 IANA CoRE parameters 9 registration 10 draft-groves-core-rfc6690up-01 12 Abstract 14 [RFC6690] defines the resource type 'rt' and interface description 15 'if' link attributes and defines procedures for registering values. 16 Currently each 'rt' and 'if' attribute value must be registered with 17 IANA. This specification updates the process to enable organisation 18 prefixes to be registered allowing organisations to manage their own 19 namespace within a certain set of rules. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 21, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. Organisation Prefix . . . . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Constrained RESTful Environments (CoRE) Parameters 61 Registry Update . . . . . . . . . . . . . . . . . . . . . 5 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 8.2. Informative References . . . . . . . . . . . . . . . . . 7 67 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Requirements Language 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 74 "OPTIONAL" in this document are to be interpreted as described in 75 [RFC2119]. 77 2. Introduction 79 [RFC6690] "Constrained RESTful Environments (CoRE) Link Format" 80 defines the Resource Type 'rt' and Interface Description 'if' link 81 attributes. In order to co-ordinate the use of these attributes, 82 sections 7.4 and 7.5/[RFC6690] establish IANA registries to register 83 link attribute values for 'rt' and 'if'. 85 In order to register a new 'rt' and 'if' link attribute value the 86 [RFC5226] "Specification Required" process is followed for each 87 value. As part of the process a designated expert will examine the 88 specification to enforce a number of requirements including: 90 o Registration values MUST be related to the intended purpose of 91 these attributes as described in Section 3/[RFC6690]. 93 o Registered values MUST conform to the ABNF reg-rel-type definition 94 of Section 2/[RFC6690], meaning that the value starts with a 95 lowercase alphabetic character, followed by a sequence of 96 lowercase alphabetic, numeric, ".", or "-" characters, and 97 contains no white space. 99 o It is recommended that the period "." character be used for 100 dividing name segments and that the dash "-" character be used for 101 making a segment more readable. Example Interface Description 102 values might be "core.batch" and "core.link-batch". 104 o URIs are reserved for free use as extension values for these 105 attributes and MUST NOT be registered. 107 The IANA CoRE resource type and interface description registry can be 108 found at: IANA CoRE Registry [1]. 110 Given the scope of the Internet of Things (IoT) the potential number 111 of resource types (and to a lesser extent interface types) is 112 potentially quite large. This would lead to a large number of 113 requests for designated expert review. It would also mean additional 114 work for the IANA to process each request. 116 The current trend for the definition of resource types and interface 117 descriptions is that a few standards organisations have defined a 118 large number of values. 120 For example the "OIC Resource Type Specification v1.1.0" [OICResSpec] 121 contains 64 resource types. 123 ETSI oneM2M also defines a large number of resource types. For 124 example is "Home Appliances Information Model and Mapping" 125 [oneM2MTS0023]. 127 The Open Mobile Alliance (OMA) also make use of resources types. 129 The above three organisations also have their own registry and 130 procedures for adding resource types. Trying to keep the IANA 131 registry aligned with the individual organisation registries would 132 also add additional burden. 134 A significant amount of work could be saved by allowing organisations 135 to register a prefix under which they can administer their own 136 resources negating the need for the IANA and the designated IANA 137 expert to be involved for each resource registration. 139 There were discussions ath the IETF#97 meeting in Seoul about how to 140 tackle this issue. There were broadly two camps in the discussion: 142 1 - Prefixes are a bad idea as they discourage people from resource 143 re-use and create little "kingdoms". 145 2 - Prefixes are OK. They've been used before and people will 146 coalesce on a common set eventually. 148 Clearly some sort of middle ground is needed to move forward. 150 Clearly resource re-use is a valid goal. It order for this to occur 151 organisations/people requesting a new resource type would need to 152 consider the existing resource types and see if it is applicable to 153 them. Presumably if they can't use an existing type then they must 154 have a reason why? One approach could be to introduce a new step 155 into the registration process where the requester must specify any 156 similar resources and why they cannot be used. This does of course 157 add extra burden on the requester to document it and extra burden on 158 the expert to evaluate it. Then there is the issue of what suffices 159 for the analysis and what are the criteria for the expert to accept 160 it? This may not result in reduced registrations but instead create 161 more workload for registrations. 163 Currently all the rt registrations have been from standards 164 organisations not individuals. The process for registration needs to 165 be simple enough that people/companies have a incentive to register 166 than rather than simply use and squat on a name without registering 167 it. 169 It does have to be noted that today there is nothing stopping people/ 170 organisations from duplicating resources in their registration. An 171 organisational prefix would not make this worse. 173 *Editor's note: Interface descriptions should be considered* 175 This specification updates the [RFC6690] IANA registration procedures 176 to allow the possibility to register a pre-fix. 178 3. Organisation Prefix 180 As indicated by [RFC6690] registered values MUST conform to the ABNF 181 reg-rel-type definition, meaning that the value starts with a 182 lowercase alphabetic character. Therefore an organisation 183 registering a prefix MUST register a lowercase alphabetic sequence of 184 characters. It MUST be followed by a ".". 186 For example: "foo." 188 This will allocate the namespace "foo." to the organisation. The 189 organisation will then be responsible for maintaining resources 190 within this name space. 192 E.g. "foo.sensor", "foo.actuator" could be allocated without 193 requiring registration with IANA. 195 4. Security Considerations 197 This specification updates the [RFC6690] IANA Considerations. No 198 additional protocol security impacts to what is already described in 199 [RFC6690] are foreseen. 201 The use of organisational prefixes introducing the possibility that 202 people request prefixes for an organisation that they do not 203 represent. The IANA considerations in this specification require 204 that the designated expert determine if the person requesting a 205 prefix represents the organisation related to the prefix. 207 5. IANA Considerations 209 5.1. Constrained RESTful Environments (CoRE) Parameters Registry Update 211 This specification updates the Constrained RESTful Environments 212 (CoRE) Parameter Registry by allowing the registration of an 213 organisation prefix for Resource Type (rt=) and Interface Description 214 (if=) Link Target Attribute values. 216 Organisation prefixes are registered by using the Specification 217 Required policy (see [RFC5226], which requires review by a designated 218 expert appointed by the IESG or their delegate. 220 The designated expert will enforce the following requirements: 222 o The registered prefix MUST conform to the ABNF reg-rel-type 223 definition of Section 2/[RFC6690], meaning that the value starts with 224 a lowercase alphabetic character followed by a period ".". 226 o The registered prefixes are assigned on a first come first served 227 basis. 229 o Prefixes must be requested by a representative of the organisation 230 applying for the prefix and must be representative of the 231 organisation. E.g. organisation "foo" trying to register "ietf." 232 would not be representative. 234 The specification MUST: 236 o Specify the procedures for registering values within the prefixed 237 namespace. It ideally SHOULD provide a link where current and 238 future registered values may be found. 240 o Indicate that registered values within the prefixed namespace MUST 241 conform to the ABNF reg-rel-type definition of 242 Section 2/[RFC6690]. This means that the prefix MUST be followed 243 by a sequence of lowercase alphabetic, numeric, ".", or "-" 244 characters, and contains no white space. Note: It is not 245 recommended to immediately follow the prefix with an additional 246 period ".", e.g. "foo..". 248 o Use the recommendation that the period "." character be used for 249 dividing name segments and that the dash "-" character be used for 250 making a segment more readable. Example Interface Description 251 values might be "core.batch" and "core.link-batch". 253 Registration requests consist of the completed registration template 254 below, with the reference pointing to the required specification. To 255 allow for the allocation of values prior to publication, the 256 designated expert may approve registration once they are satisfied 257 that a specification will be published. 259 The registration template for both sub-registries is: 261 o Prefix Value: 263 o Description: 265 o Reference: 267 o Notes: [optional] 269 Registration requests should be sent to the core-parameters@ietf.org 270 mailing list, marked clearly in the subject line (e.g., "NEW RESOURCE 271 TYPE PREFIX - example" to register an "example" relation type or "NEW 272 INTERFACE DESCRIPTION PREFIX - example" to register an "example" 273 Interface Description). 275 Handling and the decision process is as per section 7.4/[RFC6690]. 277 6. Acknowledgements 279 TBD 281 7. Changelog 283 draft-groves-core-rfc6690up-01: 285 o Keepalive update. No changes. 287 8. References 289 8.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 297 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 298 DOI 10.17487/RFC5226, May 2008, 299 . 301 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 302 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 303 . 305 8.2. Informative References 307 [OICResSpec] 308 "OIC Resource Type Specification v1.1.0", 2016, 309 . 312 [oneM2MTS0023] 313 "TS 0023 v2.0.0 Home Appliances Information Model and 314 Mapping", 2015, 315 . 317 8.3. URIs 319 [1] http://www.iana.org/assignments/core-parameters/core- 320 parameters.xhtml 322 Authors' Addresses 324 Christian Groves 325 Australia 327 Email: cngroves.std@gmail.com 329 Weiwei Yang 330 Huawei 331 P.R.China 333 Email: tommy@huawei.com