idnits 2.17.1 draft-salgueiro-vcarddav-kind-device-07.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 : ---------------------------------------------------------------------------- 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 (January 15, 2013) is 4119 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 VCARDDAV G. Salgueiro 3 Internet-Draft J. Clarke 4 Intended status: Standards Track P. Saint-Andre 5 Expires: July 19, 2013 Cisco Systems 6 January 15, 2013 8 vCard KIND:device 9 draft-salgueiro-vcarddav-kind-device-07 11 Abstract 13 This document defines a value of "device" for the vCard KIND property 14 so that the vCard format can be used to represent computing devices 15 such as appliances, computers, or network elements (e.g., a server, 16 router, switch, printer, sensor, or phone). 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 http://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 July 19, 2013. 35 Copyright Notice 37 Copyright (c) 2013 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 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 59 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 62 1. Introduction 64 Version 4 of the vCard specification [RFC6350] defines a new "KIND" 65 property to specify the type of entity that a vCard represents. 66 During its work on the base vCard4 specification, the VCARDDAV 67 Working Group defined values of "individual", "org", "group", and 68 "location" for the KIND property. 70 During working group discussion of the document that became 71 [RFC6473], consideration was given to defining a more general value 72 of "thing", but it was decided to split "thing" into software 73 applications and hardware devices and to define only the 74 "application" value at that time. Since then, use cases for device 75 vCards have emerged. These use cases involve using vCards as a 76 primer for inventory and asset tracking data specific to network 77 elements. Therefore, this document complements [RFC6473] by defining 78 a value of "device" for the KIND property to represent computing 79 devices such as appliances, computers, or network elements. In this 80 context, the concept of a device is constrained to computing devices 81 and thus is distinct from purely mechanical devices such as 82 elevators, electric generators, etc. that cannot communicate in any 83 way over a network. This does not preclude, however, network- 84 attached sensors that are connected to such mechanical devices. 86 2. Scope 88 When the KIND property has a value of "device", the vCard represents 89 a computing device such as an appliance, a computer, or a network 90 element (e.g., a server, router, switch, printer, sensor, or phone). 91 More formally, a "device" is functionally equivalent to the "device" 92 object class used in the Lightweight Directory Access Protocol 93 [RFC4519] as derived from the Open Systems Interconnection model 94 [X.521] [X.200]. However, whereas [X.521] specifies that devices are 95 "physical" elements, a device in this context can also be virtual 96 such as a virtual machine running within another physical element. 97 As one example of the "device" KIND, vCards can be embedded into 98 devices at manufacturing time such that basic information such as 99 serial number, support email, and documentation URL can be retrieved 100 upon initial deployment. This vCard can be modified after the device 101 is deployed to contain user-specified data about the device's 102 characteristics. The vCard data can therefore be used for both asset 103 tracking and operational purposes. 105 A device might have a number of embedded vCards for varying purposes. 106 The process for discovering and accessing these vCards is 107 purposefully left unspecified in this document as this process could 108 rely on any mechanism that makes sense for the device in question. 110 For example, a device could have one or more of the following vCard 111 instances: 113 o The device itself. For example, the FN ("full name") property 114 might represent the hostname of a computing device, the URL 115 property might represent a website that contains details on where 116 to find documentation or get further information about the device, 117 the KEY property might represent a digital certificate that was 118 provisioned into the device at the time of manufacture 119 [IEEE.802.1AR], or a public key certificate previously provisioned 120 into the device, and the ADR, GEO, and TZ properties might 121 represent the physical address, geographical location, and 122 timezone where the device is deployed. 124 o An organization or person that produces or manufactures the 125 device. 127 o A person or role that maintains or administers the device. 129 o Application-level vCards as described in [RFC6473] for each 130 application installed on the device. 132 When a device has vCards other than its KIND:device vCard, those 133 vCards can be linked together with RELATED (see the definition of the 134 RELATED organizational property in Section 6.6.6 of [RFC6350]). In 135 multi-vCard instances the KIND:device vCard would use the RELATED 136 property to express the relationship with the ancillary vCard(s). 137 Those supplementary vCards need not use RELATED to point back to the 138 KIND:device vCard. In this manner, the vCard for the device itself 139 can be easily distinguished from vCards referring to the vendor 140 organization, device administrator, and installed applications. 142 The following base properties make sense for vCards that represent 143 devices (this list is not exhaustive, and other properties might be 144 applicable as well): 146 * ADR 147 * EMAIL 148 * FN 149 * GEO 150 * IMPP 151 * KEY 152 * KIND 153 * LANG 154 * LOGO 155 * NOTE 156 * ORG 157 * PHOTO 158 * RELATED 159 * REV 160 * SOURCE 161 * TEL 162 * TZ 163 * UID 164 * URL 166 Although it might be desirable to define a more fine-grained taxonomy 167 of devices (e.g., a KIND of "device" with a subtype of "router" or 168 "computer"), such a taxonomy is out of scope for this document. 170 3. Example 172 The following is an example of a router device that contains both 173 manufacturing details as well as post-deployment attributes and uses 174 the XML representation of vCard (xCard) described in [RFC6351]. This 175 vCard points to another, related vCard that contains the details of 176 an administrative contact for the device. This vCard also leverages 177 the extensibility of the xCard format to reference additional 178 namespaces in order to provide richer details about the given device 179 (e.g., the serial number and software version are specified as xCard 180 extensions). 182 183 device 184 185 186 x-model-name 187 188 RTR1001 189 190 core-rtr-1.example.net 191 http://www.example.com/support/index.html 192 support@example.com 193 194 195 x-local-support 196 197 network-support@example.net 198 199 xmpp:core-rtr-1@example.net 200 201 202 contact 203 204 urn:uuid:5CEF1870-0326-11E2-A21F-0800200C9A66 205 206 http://www.example.com/images/logo.png 207 geo:35.82,-78.64 208 America/New_York 209 20120104T213000Z 210 urn:uuid:00CCFB88-155F-40F6-B9D9-B04D134860C0 211 212 FTX1234ABCD 213 214 215 216 x-contract-number 217 218 1234567 219 220 221 00-00-5E-00-00-01 222 223 224 2.1.5 225 226 228 4. IANA Considerations 230 IANA is asked to add the following entry to the "vCard Property 231 Values" registry table 232 (http://www.iana.org/assignments/vcard-elements#property-values): 234 +----------+--------+-----------+ 235 | Property | Value | Reference | 236 +----------+--------+-----------+ 237 | KIND | device | RFCXXXX | 238 +----------+--------+-----------+ 240 Table 1: IANA Registration of KIND:device vCard Property Value 242 In conformance with Section 10.2.6 of [RFC6350], the registration 243 template is as follows: 245 Value: device 247 Purpose: The entity represented by the vCard is a computing device 248 such as an appliance, computer, or network element. 250 Conformance: This value can be used with the "KIND" property. 252 Example: See Section 3 of RFCXXXX. 254 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 255 this specification, and remove this paragraph on publication.]] 257 5. Security Considerations 259 Registration of this vCard KIND to represent devices does not in 260 itself introduce security considerations beyond those specified for 261 vCards in general as described in [RFC6350]. Nevertheless, risks can 262 arise for vulnerable Internet connected devices as a result of the 263 publication of the identification details provided by device vCards. 264 Well-known publicly accessible device vCard repositories, while not 265 defined in this document, can increase the probability of an exploit 266 of an existing vulnerability, especially for devices with no good way 267 to update their software or firmware. It is the responsibility of 268 the device administrator to adhere to best current security practices 269 and proper software upgrade and security patch strategies to mitigate 270 vulnerability to attack. Specifications defining device-specific 271 vCard extensions or profiles that might be included in such vCards 272 also need to consider this potential increased risk. 274 6. References 276 6.1. Normative References 278 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 279 August 2011. 281 6.2. Informative References 283 [IEEE.802.1AR] 284 Institute of Electrical and Electronics Engineers, "Secure 285 Device Identity", IEEE 802.1AR, 2009. 287 [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol 288 (LDAP): Schema for User Applications", RFC 4519, 289 June 2006. 291 [RFC6351] Perreault, S., "xCard: vCard XML Representation", 292 RFC 6351, August 2011. 294 [RFC6473] Saint-Andre, P., "vCard KIND:application", RFC 6473, 295 December 2011. 297 [X.200] International Telecommunications Union, "Information 298 Technology - Open Systems Interconnection - Basic 299 Reference Model: The Basic Model", ITU-T Recommendation 300 X.521, ISO Standard 9594-7, February 2001. 302 [X.521] International Telecommunications Union, "Information 303 Technology - Open Systems Interconnection - The Directory: 304 Selected Object Classes", ITU-T Recommendation X.200, 305 ISO Standard 7498-1, July 1994. 307 Authors' Addresses 309 Gonzalo Salgueiro 310 Cisco Systems 311 7200-12 Kit Creek Road 312 Research Triangle Park, NC 27709 313 US 315 Phone: +1-919-392-3266 316 Email: gsalguei@cisco.com 317 Joe Clarke 318 Cisco Systems 319 7200-12 Kit Creek Road 320 Research Triangle Park, NC 27709 321 US 323 Phone: +1-919-392-2867 324 Email: jclarke@cisco.com 326 Peter Saint-Andre 327 Cisco Systems 328 1899 Wynkoop Street, Suite 600 329 Denver, CO 80202 330 USA 332 Phone: +1-303-308-3282 333 Email: psaintan@cisco.com