idnits 2.17.1 draft-mcfadden-smart-endpoint-taxonomy-for-cless-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 ([I-D:draft-taddei-smart-cless-introduction]), 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 == Line 511 has weird spacing: '...es from the d...' -- The document date (February 5, 2020) is 1540 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D:draft-taddei-smart-cless-introduction' is mentioned on line 48, but not defined == Missing Reference: 'TECE' is mentioned on line 265, but not defined == Unused Reference: '1' is defined on line 666, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 676, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMART M McFadden 2 Internet Draft internet policy advisors ltd 3 Intended status: Informational February 5, 2020 4 Expires: July 30, 2020 6 Endpoint Taxonomy for CLESS 7 draft-mcfadden-smart-endpoint-taxonomy-for-cless-01 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on August 4, 2020. 32 Copyright Notice 34 Copyright (c) 2020 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 48 A separate document [I-D:draft-taddei-smart-cless-introduction] 49 (CLESS) attempts to establish the capabilities and limitations of 50 endpoint-only security solutions and explore potential alternative 51 approaches. That document discusses endpoints in general terms. It 52 has been suggested that there are classes of endpoints that have 53 different characteristics. Those classes may have completely 54 different threat landscapes and the endpoints may have completely 55 different security capabilities. In support of the work on CLESS, 56 this document provides a taxonomy of endpoints that is intended to 57 provide a foundation for further work on CLESS and research on 58 approaches to providing endpoint security alternatives in a diverse 59 group of settings. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Conventions used in this document..............................4 65 3. Problem Statement..............................................4 66 4. The Endpoint in CLESS..........................................4 67 5. Taxonomy and Hierarchy.........................................5 68 6. Taxonomy.......................................................6 69 6.1. Traditional and Enterprise Computing Equipment [TECE].....6 70 6.1.1. Description..........................................6 71 6.1.2. Endpoint characteristics.............................7 72 6.2. Personal Computing Equipment..............................7 73 6.2.1. Description..........................................7 74 6.2.2. Endpoint characteristics.............................8 75 6.3. Human Interface Devices...................................8 76 6.3.1. Endpoint description.................................8 77 6.3.2. Endpoint characteristics.............................9 78 6.4. Human Sensor Devices......................................9 79 6.4.1. Endpoint characteristics............................10 80 6.5. Non-human Sensor Devices.................................10 81 6.5.1. Endpoint Description................................10 82 6.5.2. Endpoint characteristics............................11 83 6.6. Peripheral Computing Equipment and Embedded Endpoints....11 84 6.6.1. Endpoint Description................................11 85 6.6.2. Endpoint characteristics............................12 86 6.7. Internet Infrastructure Devices..........................12 87 6.7.1. Endpoint Description................................12 88 6.7.2. Endpoint characteristics............................13 89 6.8. Application Layer Endpoints..............................13 90 6.8.1. Description.........................................13 91 6.8.2. Endpoint Characteristics............................13 92 6.9. Edge Network and Acquisition Endpoints...................14 93 6.9.1. Description.........................................14 94 6.9.2. Endpoint characteristics............................14 95 7. Security Considerations.......................................15 96 8. IANA Considerations...........................................15 97 9. References....................................................15 98 9.1. Normative References.....................................15 99 9.2. Informative References...................................15 100 10. Acknowledgments..............................................15 101 Appendix A. Document History.....................................16 103 1. Introduction 105 A document entitled "Capabilities and Limitations of an Endpoint-only 106 Security Solution (CLESS) [I-D. draft-taddei-smart-cless- 107 introduction-02] attempts to initiate research into the limits of 108 endpoint-only security solutions. The document identifies changes in 109 technology, economics and protocol development that have impacted the 110 provision of endpoint security. 112 The CLESS introduction focuses on endpoints that are User Equipment 113 rather than hosts. Even so, this encompasses an enormous variety of 114 possible endpoints. CLESS takes a unified view of endpoints - seeing 115 them all as one type. 117 However, it seems reasonable to suggest that, in the huge variety of 118 types of endpoints, there are categories of similarity. These 119 categories are important because categories of endpoint devices may 120 share particular advantages or limitations for endpoint security. 121 While CLESS provides a clear model for understanding some of the 122 limitations of endpoint security in today's networks, it is very 123 likely that more specificity is needed. 125 This draft attempts to suggest a Taxonomy of Endpoints as a 126 foundation for further work on CLESS. The goal is to identify 127 classes of endpoints with similar characteristics. Those 128 characteristics may lead to the discovery that the devices in a 129 particular category share similar characteristics for endpoint 130 security. 132 It is essential to understand that this taxonomy is intended as a 133 foundation for work on CLESS and is not an all-purpose guide to the 134 enormous breadth of devices that are or could be endpoints on public 135 or private networks. Others have attempted to provide classifications 136 for end devices, but they are not focused on the issues related to 137 endpoint security. In addition, most are almost immediately out-of- 138 date when published. 140 This document takes a different approach: the taxonomy here is 141 intended to support the work of CLESS and provide a classification 142 system that may make it possible to group endpoints in related 143 categories for the purpose of discussing their security 144 characteristics. While a general-purpose taxonomy of Internet 145 endpoints might be useful in a variety of settings, it is not the 146 intended goal of this document. 148 In addition, this document does not attempt to assess and document 149 the endpoint security characteristics of each part of the taxonomy. 150 The work of identifying advantages and limitations of specific 151 classes of endpoints is envisioned as future work on CLESS. 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 3. Problem Statement 161 CLESS attempts to provide an analysis of the current state of the 162 provision of endpoint security. It does that by providing a 163 provisional definition of an endpoint and then examining the 164 advantages and limitations of providing security at that endpoint. 166 The original approach to CLESS divides the universe of endpoints into 167 User Equipment (UE) and hosts - and then focuses entirely on User 168 Equipment. 170 User Equipment encompasses a very broad set of endpoints. It may be 171 possible to provide a stronger set of device type groupings. 172 Endpoints in the same groups may share security chrematistics that 173 are particular to that group. The fundamental question is: can a 174 taxonomy of endpoint devices be created that allows for grouping of 175 endpoints that have similar security characteristics? 177 If it is possible to answer that question in the affirmative, then 178 research can be done on the security characteristics of each category 179 and influence the development of protocols that have the greatest 180 impact for those type of devices. 182 4. The Endpoint in CLESS 184 CLESS simplifies the representation of an endpoint by making the 185 following generalization: 187 +------------------------------------------------+ 188 | | 189 | Application | 190 | | 191 |------------------------------------------------| 192 | | 193 | OS / Execution Environment | 194 | | 195 |------------------------------------------------| 196 | | 197 | Hardware | 198 | | 199 +------------------------------------------------+ 201 Figure 1 Endpoint Generalization in CLESS 203 This simplification means that there are many combinations of 204 hardware, operating systems, execution environments and applications. 205 It also means that any of these three layers can be an endpoint for 206 the purposes of a discussion of endpoint security. 208 CLESS suggests that we consider endpoints including those which have 209 a variety of power, computational, storage and network capacities. It 210 is possible that grouping devices with similar characteristics will 211 help in identifying categories of devices that share similar endpoint 212 security characteristics. 214 5. Taxonomy and Hierarchy 216 One suggestion for the taxonomy for endpoints is to consider a 217 hierarchy of endpoints that collects similar endpoint types in large 218 categories and then distinguishes between them ion "sub-groups" or 219 lower levels of the taxonomy. 221 The advantage to CLESS is that the groupings may provide a way to 222 categorize threats and mitigations to large classes of endpoints on 223 the Internet while providing the ability for differentiation. An 224 example might be a class of endpoints characterized as "constrained 225 devices." 227 As an example, "constrained devices" might be further subdivided into 228 sub-classes such as sensors, embedded processors, specific (or, 229 special) purpose single-use processors, mesh gateways, and so forth. 230 It can even be imagined that the second level of the hierarchy could 231 be further subdivided by further distinguishing the endpoint types. 233 The current version of the draft does not take this approach. One of 234 the goals of the endpoint taxonomy is to provide enough 235 differentiation and specificity to ensure that a later CLESS draft 236 can successfully discuss common threats and mitigations for each of 237 the categories in the taxonomy. By providing a ever greater hierarchy 238 of endpoint types, it becomes difficult to scale a CLESS document 239 that discusses threats and mitigations to the highly specific 240 endpoint types. 242 [Editor's note -> adding hierarchy was a suggestion at the Prague 243 IETF 104 meeting. It is possible, based on further input that more 244 detailed hierarchy could be considered for CLESS endpoints, but that 245 has not been added to this version of the endpoint taxonomy.] 247 6. Taxonomy 249 Others have attempted to provide general-purpose taxonomy and device 250 classification guides (informative references to be provided in a 251 later draft version). In some settings automated detection and 252 classification of devices provides an essential step in providing 253 appropriate access control and security services. 255 General-purpose classification systems tend to ossify or become 256 enormously complex. Classification has come from commercial entities, 257 computer science organizations, the academic community and even 258 regional collections of cooperating national governments. 260 For the purposes of providing a taxonomy for CLESS, we limit the 261 discussion to a taxonomy for endpoints only. We divide endpoints into 262 nine different classes and then attempt to carefully describe the 263 characteristics of devices in each class. 265 6.1. Traditional and Enterprise Computing Equipment [TECE] 267 6.1.1. Description 269 Traditional and Enterprise Computing Equipment is characterized by 270 its extremely high-capacity for transactional volume, storage and 271 shared user population. TECE forms the backbone of high-volume, high- 272 availability transactional computing and is provided in both physical 273 and virtualized forms. 275 Traditional computing endpoints are shared computing environments 276 characterized by centralized, shared computing. These endpoints are 277 often in large scale data centers. These endpoints are capable of 278 high-availability, substantial requirements for power and 279 environmental control. These endpoints are also characterized by very 280 complex operating systems and user environments. 282 6.1.2. Endpoint characteristics 284 o Cost - these endpoints are characterized by extremely high cost. 286 o Physical size - these are very large endpoints, not suitable or 287 intended for use by an individual. 289 o Network link characteristics - capable of supporting extremely 290 high bandwidth. 292 o User interface - very complex and shared among multiple 293 individuals. 295 o Processing power - extremely high processing capability. 297 o Physical power - requires substantial provision of electrical 298 power and environmental controls. 300 o Code complexity - Extremely high support for very complex code 301 including parallelism, multitasking and multithreaded execution. 303 6.2. Personal Computing Equipment 305 6.2.1. Description 307 These are endpoints designed or intended to be used by an individual. 308 They can be delivered as fixed, portable or virtual instantiations of 309 the endpoint. It should be noted that virtual instantiations of 310 endpoints introduce complexities in defining the characteristics of 311 the endpoints. In each case, the device supports a mechanism for 312 human-interface and has the capability for both local storage and 313 processing. The personal computing equipment class is also 314 characterized by relatively low cost and power requirements. 316 This class of endpoint is also characterized by the devices 317 supporting multiple purpose use. This class is divided into two sub- 318 classes: fixed and mobile endpoints. The mobile subclass is further 319 divided into four other subclasses: laptops, tablets, intelligent 320 phones, and ultraportable personal computing equipment. 322 Personal computing endpoints usually have at least one, and often 323 many, network links - often supporting a variety of network 324 connectivity technologies. These endpoints are also characterized by 325 having a human interface - either integral to the computing device 326 itself or supplied externally to the computing device. 328 6.2.2. Endpoint characteristics 330 o Cost - these endpoints have a huge range of costs, from extremely 331 inexpensive for simple "personal computer on a board" endpoints to 332 moderately expensive for specially configured laptop and fixed 333 devices. 335 o Physical size - the physical size of these devices range from 336 handheld to a small cabinet for fixed, desktop units. 338 o Network link characteristics - personal computing endpoints are 339 often characterized by supporting multiple connectivity 340 technologies. 342 o User interface - personal computing endpoints are characterized by 343 having user interfaces designed for an individual. The interface 344 varies from simple, text-based interaction to gesture, touch and 345 voice control. 347 o Processing power - these endpoints are characterized by a 348 significant range of processing power: from single CPU units to 349 endpoints that can support multiple concurrent processes. 351 o Physical power - personal computing endpoints are characterized by 352 using either traditional mains power or power supplied by a 353 battery. 355 o Code complexity - personal computing endpoints support complex 356 code and often parallel and multithreaded execution of code. 358 6.3. Human Interface Devices 360 6.3.1. Endpoint description 362 Human interface transactions begin with a task-related goal for a 363 user. This leads to a user behavior (such as pointing, typing or 364 touching) which occurs in the current computing environment. The 365 user's action then should trigger an event in the current computing 366 environment. 368 Early computer science research breaks the taxonomy for Human 369 Interface Devices into four large categories: input devices, pointing 370 devices, indirect pointing and speech recognition. More recent 371 research adds neural interfaces, VR sensors, and human attribute 372 sensors. In all of these cases, the endpoints have the goal of 373 providing a mechanism for user navigation, interconnection, form 374 filling, menu interaction, data entry or sensing of human input 375 (although not to be confused with the following category in the 376 taxonomy). The result is that this category of the taxonomy has been 377 characterized by extremely limited computing capability in the past. 378 In contemporary networks the human interface devices are far more 379 complex and, as a result, subject to a wider collections of risks as 380 endpoints. 382 Since human interface devices are often the mechanism that provides 383 control of a computing resource, attacks on those devices are of 384 particular concern. In the past, the idea that there was an external 385 threat to a mouse or a pointing device would be ignored. In contrast, 386 today's voice actuated input devices and VR interfaces are 387 sophisticated enough to represent a real platform for attack. 389 6.3.2. Endpoint characteristics 391 o Cost 393 o Physical size 395 o Network link characteristics 397 o User interface 399 o Processing power 401 o Physical power 403 o Code complexity 405 6.4. Human Sensor Devices 407 Description 409 These are endpoints whose primary purpose is to sense, store, 410 transmit or process information about a human being. These endpoints 411 are characterized as having use cases in health and wellness 412 monitoring, human performance enhancement, personalized medicine and 413 human safety. 415 The endpoints are characterized as sensor devices with the capacity 416 to sense, store and report on data collected on an individual. The 417 sensor may be multimodal. These endpoints are almost always 418 characterized by have a battery for power and having limited storage, 419 networking and processing capabilities. 421 6.4.1. Endpoint characteristics 423 o Cost - Human Sensor Endpoints can range in cost from very low (for 424 instance a heartbeat sensor) to quite expensive (a sensor built 425 into an implanted device). 427 o Physical size - human sensors are very small and almost always 428 portable. 430 o Network link characteristics - human sensors usually have a single 431 network like technology available and are capable of very limited 432 bandwidth utilization on that link. 434 o User interface - human sensors have extremely limited, or no, user 435 interface. 437 o Processing power - human sensors are characterized by having 438 limited processing power - often incorporating only the ability to 439 collect store and forward sensed information. 441 o Physical power - human sensors are characterized by being powered 442 by internal batteries 444 o Code complexity - human sensors are not usually capable of running 445 complex code. Often, the capability of the endpoint is to simply 446 sense, store and forward data without reporting and analysis of 447 that data. 449 6.5. Non-human Sensor Devices 451 6.5.1. Endpoint Description 453 These endpoints are capable of sensing, storage, communication and 454 possibly some computation. They are characterized by having very low 455 bandwidth radios, a battery for power, sensor technology and a small 456 processor. Unlike in Section 5.4, these devices are not intended to 457 sense human-related information. 459 Compared with Human Sensors, non-human sensors often have a variety 460 of communications technologies available - for instance, self- 461 organizing into mesh networks. 463 6.5.2. Endpoint characteristics 465 o Cost - Non-human Sensor Endpoints can range in cost from very low 466 (for instance, a simple temperature sensor) to quite expensive (a 467 sensor built into an implanted device. 469 o Physical size - Non-human sensors are often small and almost 470 always portable. 472 o Network link characteristics - Non-human sensors usually have a 473 single network like technology available but the topology of those 474 network links can be highly varied. Quite often these devices are 475 capable of very limited bandwidth utilization on the link to which 476 they are attached. 478 o User interface - non-human sensors have extremely limited, or no, 479 user interface. 481 o Processing power - non-human sensors are characterized by having 482 limited processing power - often incorporating only the ability to 483 collect store and forward sensed information. Some non-human 484 sensors have the capability to process stored data, but usually 485 this is limited. 487 o Physical power - - 489 o Code complexity - non-human sensors are not usually capable of 490 running complex code. Often, the capability of the endpoint is to 491 simply sense, store and forward data without reporting and 492 analysis of that data. 494 6.6. Peripheral Computing Equipment and Embedded Endpoints 496 6.6.1. Endpoint Description 498 These are endpoints that are "embedded" in devices that may have a 499 different primary function. An example is a network endpoint in a 500 printer that supports remote access, configuration and printing. 501 Another example is an endpoint in an appliance that has a different 502 primary function (for instance, a refrigerator). 504 In either case, the endpoint is characterized as being added to 505 another system, machine or peripheral. 507 These devices are characterized as being specialized for their 508 particular use case and function. Their specific characteristics 509 often depend upon the system, device or peripheral in which they are 510 being hosted. As an example, the embedded endpoint gets its physical 511 power and networking capabilities from the device in which it is 512 connected. 514 6.6.2. Endpoint characteristics 516 o Cost - almost never available as a standalone device - instead, 517 always embedded into the peripheral or system which is hosting it. 519 o Physical size - almost always very small - to be embedded into 520 some other system or device. 522 o Network link characteristics - dependent on network services 523 available from the host device and not always IP-based. 525 o User interface - almost always provided by the "hosting" device. 526 Many embedded endpoints share a user interface with the 527 configuration and control tool for the underlying device. 529 o Processing power - usually limited and constrained by the use 530 case. Some embedded endpoints provide remote access to the 531 underlying resources provided by the processor. 533 o Physical power - generally supplied by the "host" system or 534 device. 536 o Code complexity - limited and almost always constrained by use 537 case. 539 6.7. Internet Infrastructure Devices 541 6.7.1. Endpoint Description 543 Internet Infrastructure endpoints are the physical components that 544 are used to deploy a network. There is a huge variety of these 545 devices, but they all share two common properties: they are building 546 blocks of the underlying network infrastructure and they also can be 547 endpoints of a network conversation. 549 But, there's an important question here. CLESS specifically rules out 550 network infrastructure in its discussion. Should the taxonomy for 551 CLESS incorporate endpoints that are part of the network 552 infrastructure? Said a different way: is network infrastructure out 553 of scope for CLESS? 555 6.7.2. Endpoint characteristics 557 [ Editor's note --> TBD, depending on the answer to the question in 558 section 6.7.1 ] 560 o Cost 562 o Physical size 564 o Network link characteristics 566 o User interface 568 o Processing power 570 o Physical power 572 o Code complexity 574 6.8. Application Layer Endpoints 576 6.8.1. Description 578 A significant trend in the contemporary public Internet is to have 579 applications act as completely independent agents - a situation where 580 the application itself provides the necessary infrastructure (for 581 instance, domain name resolution) to provide services. An example 582 would be a web browser that independently resolved domain names and 583 established secure communication channels independently. 585 The traffic between the application and the servers it uses might not 586 be available for analysis by security software. As a result, 587 application-based endpoints would have the characteristic of having 588 to provide security services (for instance, traffic security or 589 malware detection) for itself. 591 This type of endpoint also has the characteristic of potentially 592 having adverse impacts on other applications running on the same 593 platform. For example, if several applications are provisioning their 594 own infrastructure services, then those services are being duplicated 595 on that platform. For security related infrastructure there would be 596 no common, platform-wide approach to securing the applications or the 597 traffic generated between the application and external servers. 599 6.8.2. Endpoint Characteristics 601 TBD 603 6.9. Edge Network and Acquisition Endpoints 605 6.9.1. Description 607 The emergence of intelligent devices and things has led to new 608 network designs where data is aggregated at points topologically 609 close to where the data is gathered. The gathered data can then have 610 the option to flow to nearby gateways, or a Wi-Fi/W-LAN (SD-WAN) 611 router/equipment, or the telco tower/rooftop towers. These often 612 perform an acquisition function that includes both aggregation and 613 data condensation. 615 They usually have some level of processing capability. The main task 616 for these devices is to collect the data from various other endpoints 617 and send the processed data upstream. In doing so, they often perform 618 some low-level data processing, such as data filtering (which 619 determines what data is sent/blocked) and data analytics. 621 The acquisition systems are often architected to talk to distributed 622 data centers and end devices; for instance, on a factory shop floor, 623 a CDN's edge PoP (Point of Presence), an edge colocation local, or a 624 metro regional datacenter for a Telco or IT Service Provider. 626 In all cases, these edge computing devices represent a newer class of 627 endpoints. These are endpoints that are not at the extreme edge of 628 the network, but provide services to the devices at those edges 629 (especially for those devices in the class discussed in section 6.4 630 and 6.5 above). 632 The threats and mitigations for this class of device is expected to 633 be significantly different from those in sections 6.4 and 6.5. 635 6.9.2. Endpoint characteristics 637 o Cost 639 o Physical size 641 o Network link characteristics 643 o User interface 645 o Processing power 647 o Physical power 649 o Code complexity 651 7. Security Considerations 653 INFO (REMOVE): Every draft MUST have a Security Considerations 654 section. 656 TBD, descriptive 658 8. IANA Considerations 660 This document has no requirements or actions for IANA. 662 9. References 664 9.1. Normative References 666 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 667 Levels", BCP 14, RFC 2119, March 1997. 669 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 670 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 671 Demon Internet Ltd., November 1997. 673 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 674 Requirement Levels", BCP 14, RFC 2119, March 1997. 676 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 677 Syntax Specifications: ABNF", RFC 2234, Internet Mail 678 Consortium and Demon Internet Ltd., November 1997. 680 9.2. Informative References 682 TBD 684 10. Acknowledgments 686 This document was prepared using 2-Word-v2.0.template.dot. 688 Appendix A. Document History 690 [[ To be removed from the final document ]] 692 -1 694 New sections on Human Interface Devices and edge network endpoints. 696 New section discussing the expansion of the hierarchy of the taxonomy 697 and reasons for not proceeding with that suggestion. 699 Editorial and grammatical corrections. 701 -0 703 Initial Internet Draft 705 Authors' Addresses 707 Mark McFadden 708 Internet policy advisors ltd 709 Madison Wisconsin US 711 Email: mark@internetpolicyadvisors.com