Network Working Group B. Nordman Internet-Draft Lawrence Berkeley National Intended status: Standards Track Laboratory Expires: April 26, 2012 October 24, 2011 Basic Device Classification draft-nordman-classification-00 Abstract This specification addresses how to communicate a basic sense of the type of each device present on the network. This is particularly important as the range of devices with connectivity greatly expands, and as indirect interests in device characteristics increase, such as energy consumption. Many applications will benefit from a single standard enumeration of basic device types. This draft does not address detailed device characteristics or subtypes. The draft also discusses related identify information. It is an initial discussion document to generate feedback and improvement. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 26, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Nordman Expires April 26, 2012 [Page 1] Internet-Draft Device Classification October 2011 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Overview As the number of types of devices that are connected to the Internet increases, it will be increasingly necessary for devices to make decisions based on the types of devices they encounter. In particular, devices may be able to discover what other devices share the same physical space, so that the range of devices that they find may be large. Basic decisions about whether or not to respond to a device can be informed by understanding the fundamental nature of each device. Detailed understanding likely requires device-specific information; this draft does not attempt to do this; it only covers a first layer of classification. Classification is proposed to be represented as a 2-byte value that corresponds to an IANA registry of devices. Other information also contributes to the identity of a device, such as brand and model, and would benefit from consistency in naming and availability. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Other Relevant Standards There are many standards that touch on topics related to this one, though generally they have a different specific purpose, or address just a small subset of the devices in scope for this standard. Thus, while they should inform the discussion, none are suitable as a replacement for or substantial basis for this one. Some example other standards and classifications are: Nordman Expires April 26, 2012 [Page 2] Internet-Draft Device Classification October 2011 * The Distributed Management Task Force (DMTF) defines a set of entity times in its Common Information Model (CIM). These include both entire devices and components of devices (components are out of scope of this proposal). * Systems for labeling retail products (e.g. Universal Product Code, UPC) embody a detailed listing of product types. * The United Nations publishes a Standard Products and Services Code, for use in facilitating electronic commerce. * There are efforts to develop standard taxonomies for heating and cooling systems in large commercial buildings. This is particularly needed since that industry has been long dominated by proprietary protocols, each with their own internal taxonomy. * Some companies have implemented information systems to describe devices. An example is the Cisco Products MIB, which provides for a device to report its model number. 4. Classification and Identity There are many standards that speak to identity on the network, or service discovery. This document does not address those topics. Rather, the classification addressed is comparable to the first impression a human being might have on a device, to recognize its core function or type. 4.1. General Issues An analogy can be drawn to the ASCII character coding system. It specifies a single simple and compact numeric correspondence for letters, numbers, and symbols. It makes no attempt to cover characteristics other than the character's identity such as font, size, etc. Because of its simplicity, it can be utilized universally, or nearly so. The concept of identity is usually for information which is unique to the entity at hand, rather than data which puts it into a group of entities. Classification of populations of entities is commonly done with a taxonomy; a system of organization or categories. Taxonomies often have multiple layers of organization with groupings having one or more common characteristics; the most widely known of these is the biological classification system which has seven layers or grouping. 4.2. Registry Proposal Classification should be a characteristic of a device that never changes, though it may be unnecessary to prohibit this. Nordman Expires April 26, 2012 [Page 3] Internet-Draft Device Classification October 2011 Classification of a device is self-determined. It will be desirable to have standard translations of the classification code into all major languages. A possible implementation of this is an IANA registry of 2-byte values for class. Each device would be a member of at most one class. The class for a particular device would be set by the manufacturer. This proposal is for a single listing of device types, as the choice of criteria for grouping might change with the particular application. As the number of device types anticipated is not so large, an application can readily impose its own categorization system on top of the basic classes. Some devices have more than one major function (e.g. a combination television and DVD player). While it would be possible to allow more than one classification, this draft is crafted on the assumption that this is unnecessary. This mechanism is not intended to solve all problems with an application understanding characteristics of devices it encounters. There are many existing mechanisms for service discovery and the like which enable much more detailed information, but none of these are universal. Categories would be drawn broadly. For example, a likely one is "refrigerator" which would encompass any device that cools its inside space regardless of size, technology, features, or intended market (e.g. residential or commercial). Obtaining more detailed information would require a different mechanism. 4.3. Application to Energy Management One application that would benefit from such a classification system is Energy Management. A management system for energy will gather up data about all devices in a building, and have no functional relationship to many of them. The energy information collected is generic to any device type; the data are unrelated to the services that the device provides functionally. Classification information may be the only data that the management system has about the device other than its identity on the network. Thus, any classification (and identity) data should be universal. Also, many buildings will be partly or entirely unmanaged, with some devices that come and go asynchronously so that classification information should be gathered automatically. With classification data, a management system can readily and Nordman Expires April 26, 2012 [Page 4] Internet-Draft Device Classification October 2011 automatically provide a breakdown of energy use by major category of device. A person may be investigating energy use in a building after some devices have left the network, or in a situation where they lack direct access to the network (an example of the latter is where the analysis is outsourced to a third party). Thus, it is desirable that the most critical information be available in what is reported during energy management queries. 5. Related Needs Beyond the basic class, it is often necessary or desirable to have the manufacturer's brand name and model number. These can be used in reports, or to help gather additional information about a device. These are text strings of some modest length. A human-readable name is often associated with such information. There are some existing MIBs which have these variables. Related to this, manufacturers often have a web page for information about each model. It would be helpful if a device could report a URL for such a page. Additionally, the page could have both human- readable and machine-readable portions, with the latter specified according to some standard format. This would enable useful information about devices to be gathered automatically by a management system. Many applications that use classification will also want to know the current location of a device, either geographically, or within a room or building. This draft does not speak to location but it is important. 6. Issues Should there be a repository somewhere of standard translations from IANA code to human languages? Where? What issues are introduced when classification is proxied for non-IP devices? 7. Security Considerations In general none. It is worth noting that a device may report a type other than what it is. Nordman Expires April 26, 2012 [Page 5] Internet-Draft Device Classification October 2011 8. Privacy Considerations None. 9. Acknowledgement We would like to thank . 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Bruce Nordman Lawrence Berkeley National Laboratory 1 Cyclotron Road Berkeley, CA 94720 USA Email: BNordman@LBL.gov Nordman Expires April 26, 2012 [Page 6]