idnits 2.17.1 draft-ietf-i2nsf-terminology-02.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 (October 23, 2016) is 2742 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-i2nsf-gap-analysis-02 == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-02 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-09 == Outdated reference: A later version (-16) exists of draft-ietf-sacm-terminology-11 == Outdated reference: A later version (-03) exists of draft-ietf-supa-generic-policy-info-model-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF S. Hares 3 Internet-Draft J. Strassner 4 Intended status: Informational Huawei 5 Expires: April 25, 2017 D. Lopez 6 Telefonica I+D 7 L. Xia 8 Huawei 9 H. Birkholz 10 Fraunhofer SIT 11 October 23, 2016 13 Interface to Network Security Functions (I2NSF) Terminology 14 draft-ietf-i2nsf-terminology-02.txt 16 Abstract 18 This document defines a set of terms that are used for the Interface 19 to Network Security Functions (I2NSF) effort. 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 29 Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other 33 documents at any time. It is inappropriate to use Internet-Drafts 34 as reference material or to cite them other than as "work in 35 progress." 37 This Internet-Draft will expire on April 25, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Simplified BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided 52 without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 6.1. Informative References . . . . . . . . . . . . . . . . . 11 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 65 1. Introduction 67 This document defines the terminology for the Interface to Network 68 Security Functions (I2NSF) effort. This section provides some 69 background on I2NSF; a detailed problem statement can be found in 70 [I-D.ietf-i2nsf-problem-and-use-cases]. Motivation and comparison to 71 previous work can be found in [I-D.ietf-i2nsf-gap-analysis]. 73 Enterprises are now considering using network security functions 74 (NSFs) hosted by service providers due to the growing challenges and 75 complexity in maintaining an up-to-date secure infrastructure that 76 complies with regulatory requirements, while controlling costs. The 77 hosted security service is especially attractive to small- and 78 medium-size enterprises who suffer from a lack of security experts 79 to continuously monitor, acquire new skills and propose immediate 80 mitigations to ever increasing sets of security attacks. Small- and 81 medium-sized businesses (SMBs) are increasingly adopting cloud-based 82 security services to replace on-premises security tools, while larger 83 enterprises are deploying a mix of traditional (hosted) and cloud- 84 based security services. 86 To meet the demand, more and more service providers are providing 87 hosted security solutions to deliver cost-effective managed security 88 services to enterprise customers. The hosted security services are 89 primarily targeted at enterprises, but could also be provided to 90 mass-market customers as well. NSFs are provided and consumed in 91 increasingly diverse environments. Users of NSFs may consume 92 network security services hosted by one or more providers, which 93 may be their own enterprise, service providers, or a combination 94 of both. 96 It is out of scope in this document to define an exhaustive list of 97 terms that are used in the security field; the reader is referred to 98 other applicable documents, such as [RFC4949]. 100 2. Conventions Used in This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in [RFC2119]. In 105 this document, these words will appear with that interpretation 106 only when in ALL CAPS. Lower case uses of these words are not to 107 be interpreted as carrying [RFC2119] significance. 109 3. Terminology 111 AAA: Authentication, Authorization, and Accounting. See individual 112 definitions. 114 Abstraction: The definition of the salient characteristics and 115 behavior of an object that distinguish it from all other types of 116 objects. It manages complexity by exposing common properties 117 between objects and processes while hiding detail that is not 118 relevant. 120 Access Control: Protection of system resources against unauthorized 121 access; a process by which use of system resources is regulated 122 according to a security policy, and is permitted by only 123 authorized entities (users, programs, processes, or other systems) 124 according to that policy [RFC4949]. 126 Accounting: The act of collecting information on resource usage for 127 the purpose of trend analysis, auditing, billing, or cost 128 allocation ([RFC2975] [RFC3539]). 130 ACL (Access Control List): This is a mechanism that implements 131 access control for a system resource by enumerating the system 132 entities that are permitted to access the resource and stating, 133 either implicitly or explicitly, the access modes granted to each 134 entity [RFC4949]. A YANG description is defined in 135 [I-D.ietf-netmod-acl-model]. 137 Action: Defines what is to be done when a set of Conditions are 138 met (See I2NSF Action). (from 139 [I-D.ietf-supa-generic-policy-info-model]). 141 Assertion: Defined by the ITU in [X.1252] as "a statement made by 142 an entity without accompanying evidence of its validity". In the 143 context of I2NSF, an assertion MAY include metadata about all or 144 part of the assertion (e.g., context of the assertion, or about 145 timestamp indicating the point in time the assertion was 146 created). The validity of an assertion cannot be verified. 147 (from [I-D.ietf-sacm-terminology]). 149 Authentication: Defined in [RFC4949] as "the process of verifying 150 a claim that a system entity or system resource has a certain 151 attribute value." (from [I-D.ietf-sacm-terminology]). 153 Authorization: Defined in [RFC4949] as "an approval that is granted 154 to a system entity to access a system resource." 155 (from [I-D.ietf-sacm-terminology]). 157 B2B: Business-to-Business. 159 Bespoke: Something made to fit a particular person, customer, or 160 company. 162 Bespoke security management: Security management systems that are 163 make to fit a particular customer. 165 Boolean Clause: A logical statement that evaluates to either TRUE 166 or FALSE. Also called Boolean Expression. 168 Capability: Defines a set of features that are available from a 169 managed entity (see also I2NSF Capability). Examples of "managed 170 entities" are NSFs and Controllers, where NSF Capabilities and 171 Controller Capabilities define functionality of an NSF and about 172 Controller, respectively. These functions may, but do not have 173 to, be used. All Capabilities are announced through the 174 Registration Interface. 176 Client: See Consumer. [Editor's note: placeholder for gradually 177 replacing Client with Consumer, since Client is too vague and 178 has other connotations (e.g., client-server)]. 180 Client-Facing Interface: See Consumer-Facing Interface. 181 See also: Interface, NSF-Facing Interface. 183 Component: An encapsulation of software that communicates using 184 Interfaces. A Component may be implemented by hardware and/or 185 software, and be represented using a set of classes. In general, 186 a Component encapsulates a set of data structures and a set of 187 algorithms that implement the function(s) that it provides. 189 Consumer: A Consumer is a Role that is assigned to an I2NSF 190 Component that represents the needs of a user of I2NSF services. 191 A consumer can send/receive information to/from another I2NSF 192 Component (e.g., for defining and monitoring security policies 193 for the Consumer's specific flows through an I2NSF 194 administrative domain). See also: Producer, Role. 196 Consumer-Facing Interface: An Interface dedicated to communication 197 with Consumers of NSF Data and Services. This is typically 198 defined per I2NSF administrative domain. See also: Interface, 199 NSF-Facing Interface. 201 Condition: A set of attributes, features, and/or values that are to 202 be compared with a set of known attributes, features, and/or 203 values in order to make a decision. A Condition, when used in the 204 context of a Policy Rule, is used to determine whether or not the 205 set of Actions in that Policy Rule can be executed or not. 206 Examples of an I2NSF Condition include matching attributes of a 207 packet or flow, and comparing the internal state of a NSF to a 208 desired state. (from [I-D.ietf-supa-generic-policy-info-model]). 210 Constraint: A Constraint is a limitation or restriction. 211 Constraints may be associated with any type of object (e.g., 212 Events, Conditions, and Actions in Policy Rules). 214 Constraint Programming: A type of programming that uses constraints 215 to define relations between variables in order to find a 216 feasible (and not necessarily optimal) solution. 218 Context: The Context of an Entity is a collection of measured and/ 219 or inferred knowledge that describe the state and the environment 220 in which an Entity exists or has existed. (from 221 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html). 223 Controller: A Controller is a management Component that contains 224 control plane functions to manage and facilitate information 225 sharing, as well as execute security functions. This definition 226 is based on that in [I-D.ietf-sacm-terminology]. 228 Control Plane: In the context of I2NSF, the Control Plane is an 229 architectural Component that provides common control functions 230 to all I2NSF Components, including some or all of the following: 231 authentication, authorization, accounting, auditing, and 232 Capability discovery and negotiation. The Control Plane 233 orchestrates the operation of the Data Plane according to 234 guidance and/or input from the Management Plane. I2NSF Components 235 with Interfaces to the Control Plane have knowledge of the 236 Capabilities of other I2NSF Components within a particular I2NSF 237 administrative domain. This definition is based on that in 238 [I-D.ietf-sacm-terminology]. See also: Data Plane, Management 239 Plane. 241 Customer: A business role of an entity that is involved in the 242 definition and/or consumption of services, and the possible 243 negotiation of a contract to use services from a Provider. 245 DC: Data Center 246 Data Model: A representation of concepts of interest to an 247 environment in a form that is dependent on data repository, data 248 definition language, query language, implementation language, and 249 protocol (typically one or more of these ). Note the difference 250 between a data **model** and a data **structure**. 251 [I-D.ietf-supa-generic-policy-info-model]. 253 Data Plane: In the context of I2NSF, the Data Plane is an 254 architectural Component that provides operational functions to 255 enable an I2NSF Component to provide and consume packets and 256 flows. See also: Control Plane, Management Plane. 258 Data Structure: A low-level building block that is used in 259 programming to implement an algorithm. A data model typically 260 contains multiple types of data structures; however, a data 261 structure does not contain a data model. Note the difference 262 between a data **model** and a data **structure**. 264 Event: An important occurrence in time of a change in the system 265 being managed, and/or in the environment of the system being 266 managed. Examples of an I2NSF Event include time and user actions 267 (e.g. logon, logoff, and actions that violate an ACL). An Event, 268 when used in the context of a Policy Rule, is used to determine 269 whether the Condition clause of an imperative Policy Rule can be 270 evaluated or not (from [I-D.ietf-supa-generic-policy-info-model]). 272 ECA: Event - Condition - Action (a type of Policy Rule). 274 Firewall (FW): A function that restricts data communication traffic 275 to and from one of the connected networks (the one said to be 276 'inside' the firewall), and thus protects that network's system 277 resources against threats from the other network (the one that 278 is said to be 'outside' the firewall) [RFC4949]. 279 [I-D.ietf-opsawg-firewalls] 281 Flow: A set of information (e.g., packets) that are related in a 282 fundamental manner (e.g., sent from the same source and sent to 283 the same destination). A common example is a sequence of packets. 284 It is the opposite of packet-based, which treats each packet 285 discretely (e.g., each packet is assessed individually to 286 determine the action(s) to be taken). 288 Flow-based NSF: A NSF that inspects network flows according to a 289 set of policies intended for enforcing security properties. Flow- 290 based security also means that packets are inspected in the order 291 they are received, and without modification to the packet due to 292 the inspection process. 294 I2NSF Agent: A software Component in a device that implements an 295 NSF. It receives provisioning information and requests for 296 operational data (e.g., monitoring data) from an I2NSF Consumer. 297 It is also responsible for enforcing the policies that it 298 receives from an I2NSF Consumer. 300 I2NSF Action: An I2NSF Action is a special type of Action that is 301 used to control and monitor aspects of flow-based Network Security 302 Functions. Examples of I2NSF Actions include providing intrusion 303 detection and/or protection, web and flow filtering, and deep 304 packet inspection for packets and flows. An I2NSF Action, when 305 used in the context of a I2NSF Policy Rule, may be executed when 306 both the Event and the Condition clauses of its owning I2NSF 307 Policy Rule evaluate to true. The execution of this Action may be 308 influenced by applicable metadata. (from 309 [I-D.ietf-supa-generic-policy-info-model]). 311 I2NSF Capability: A set of features that are available from an NSF 312 Server or an NSF Controller. While both are Capabilities, the 313 former defines functions that are available from an NSF, whereas 314 the latter defines functions that are available from a security 315 Controller or other Management Entity. This definition is based 316 on that in [I-D.ietf-sacm-terminology]. 318 I2NSF Client: See I2NSF Consumer. 320 I2NSF Component: A Component that provides one or more I2NSF 321 Services. I2NSF Components are managed and communicate with other 322 I2NSF Components using I2NSF Interfaces. 324 I2NSF Consumer: A software Component that uses the I2NSF framework 325 to read, write, and/or change provisioning and operational aspects 326 of the NSFs that it attaches to. 328 I2NSF Consumer Interface: An Interface dedicated to requesting and 329 using I2NSF Services. For example, this Interface could be used 330 to request a set of Flow Security policies from an I2NSF 331 Controller or from one or more individual NSFs. The difference is 332 that the former uses more abstract Condition matching (e.g., 333 based on tenant or customer ID), whereas the latter uses more 334 low-level Condition matching (e.g., based on flow state or fields 335 in a flow or packet). See also: Interface, I2NSF Provider 336 Interface, Client-Facing Interface, NSF-Facing Interface. 338 I2NSF Management System: I2NSF Consumers operate within the scope of 339 a network management system, which serves as a collection and 340 distribution point for I2NSF security provisioning. 342 I2NSF Policy: A set of Policy Rules that are used to manage and 343 control the changing or maintaining of the state of an instance 344 of an NSF. 346 I2NSF Policy Rule: A Policy Rule that is adapted for I2NSF usage. 347 The I2NSF Policy Rule is assumed to be in ECA form (i.e., an 348 imperative structure). Other types of programming paradigms 349 (e.g., declarative and functional) are currently out of scope. 350 An example of an I2NSF Policy Rule is, in pseudo-code: 352 IF is TRUE 353 IF is TRUE 354 THEN execute 355 END-IF 356 END-IF 358 In the above example, the Event, Condition, and Action portions 359 of a Policy Rule are all **Boolean Clauses**. 361 I2NSF Provider Interface: An Interface dedicated to providing I2NSF 362 Services. For example, this could provide Anti-Virus, (D)DoS, or 363 IPS Services. See also: Interface, I2NSF Provider Interface, 364 Client-Facing Interface, NSF-Facing Interface. 366 I2NSF Registry: A registry that contains I2NSF capability 367 information, which can be controlled by the I2NSF Management 368 System. See also: Registry. 370 I2NSF Service: A set of functions, provided by an I2NSF Consumer, 371 which are used by zero or more I2NSF Producers. Exemplary I2NSF 372 Services include Anti-Virus, Authentication, Authorization, 373 (D)DoS, Firewall, and IPS Services. See also: Interface, I2NSF 374 Provider Interface, Client-Facing Interface, NSF-Facing Interface. 376 IDS: Intrusion Detection System (see below). 378 IPS: Intrusion Protection System (see below). 380 Information Model: A representation of concepts of interest to an 381 environment in a form that is independent of data repository, 382 data definition language, query language, implementation language, 383 and protocol [I-D.ietf-supa-generic-policy-info-model]. 385 Interface: A set of operations one object knows it can invoke on, 386 and expose to, another object. It is a subset of all operations 387 that a given object implements. The same object may have multiple 388 types of interfaces to serve different purposes. An example of 389 multiple interfaces can be seen by considering the interfaces 390 include a firewall uses; these include: 392 * multiple interfaces for data packets to traverse through, 393 * an interface for a controller to impose policy, or retrieve 394 the results of execution of a policy rule. 396 See also: Consumer Interface, I2NSF Interface, Provider Interface 398 Interface Group: A set of Interfaces that are related in purpose and 399 which share the same communication mechanisms. 401 Intrusion Detection System (IDS): A system that detects network 402 intrusions via a variety of filters, monitors, and/or probes. An 403 IDS may be stateful or stateless. 405 Intrusion Protection System (IPS): A system that protects against 406 network intrusions. An IPS may be stateful or stateless. 408 Management Plane: In the context of I2NSF, the Management Plane is 409 an architectural Component that provides common functions to 410 define the behavior of I2NSF Components. The primary use of the 411 Management Plane is to transport behavioral commands, and supply 412 OAM data, for making decisions that affect behavior. Examples 413 include modifying the configuration of an I2NSF Component and 414 transporting OAM data. See also: Control Plane, Data Plane. 416 Metadata: Data that provides information about other data. 417 Examples include IETF network management protocols (e.g. NETCONF, 418 RESTCONF, IPFIX) or IETF routing interfaces (I2RS). The I2NSF 419 security interface may utilize Metadata to describe and/or 420 prescribe characteristics and behavior of the YANG data models. 422 Middlebox: Any intermediary device performing functions other 423 than the normal, standard functions of an IP router on the 424 datagram path between a source host and destination host 425 [RFC3234]. 427 Network Security Function (NSF): Software that provides a set of 428 security-related services. Examples include detecting unwanted 429 activity and blocking or mitigating the effect of such unwanted 430 activity in order to fulfil service requirements. The NSF can 431 also help in supporting communication stream integrity and 432 confidentiality. 434 NSF-Facing Interface: An Interface dedicated to communication with 435 a set of NSFs. This is typically defined per I2NSF administrative 436 domain. See also: Interface, Consumer-Facing Interface. 438 OAM: Operation, Administrative, and Management. 440 OCL (Object Constraint Language): A constraint programming language 441 that is used to specify constraints (e.g., in UML) (from 442 http://www.ietf.org/mail-archive/web/i2nsf/current/msg00762.html) 444 Policy Rule: A set of rules that are used to manage and control 445 the changing or maintaining of the state of one or more managed 446 objects. Often this is shortened to Rule or Policy (see I2NSF 447 policy rule). (from [I-D.ietf-supa-generic-policy-info-model]). 449 Profile: A structured representation of information that uses a 450 pre-defined set of capabilities of an object, typically in a 451 specific context. Zero or more Capabilities may be changed at 452 runtime. This may be used to simplify how this object interacts 453 with other objects in its environment. 455 Producer: A Producer is a Role that is assigned to an I2NSF 456 Component that can send information and/or commands to another 457 I2NSF Component. See also: Consumer, Role. 459 Registry: A logically centralized location containing data of a 460 particular type; it may optionally contain metadata, 461 relationships, and other aspects of the registered data in order 462 to use those data effectively. An I2NSF registry is used to 463 contain capability information that can be controlled by the 464 controller. 466 Registration Interface: An interface dedicated to requesting, 467 receiving, editing, and deleting information in a Registry. 469 Role: An abstraction of a Component that models context-specific 470 views and responsibilities of an object as separate Role objects. 471 Role objects can optionally be attached to, and removed from, the 472 object that the Role object describes at runtime. This provides 473 three important benefits. First, it enables different behavior 474 to be supported by the same Component for different contexts. 475 Second, it enables the behavior of a Component to be adjusted 476 dynamically (i.e., at runtime, in response to changes in context) 477 by using one or more Roles to define the behavior desired for 478 each context. Third, it decouples the Roles of a Component from 479 the Applications use that Component. 481 Service Interface: An Interface dedicated to enabling Policy Rules 482 to be managed. This is also called the I2NSF Consumer Interface. 484 Service Provider Security Controller: TBD (Editorial: Place holder 485 for a split between controller and security controller 486 definitions.) 488 Tenant: A group of users that share common access privileges to 489 the same software. An I2NSF tenant may be physical or virtual, 490 and may run on a variety of systems or servers. 492 Vendor-Facing Interface: An Interface dedicated to registering and 493 vendor-specific NSFs and Capabilities. It is also used to invoke 494 vendor-specific functionality. This is also called the NSF-Facing 495 Interface. 497 3. IANA Considerations 499 No IANA considerations exist for this document. 501 4. Security Considerations 503 This is a terminology document with no security considerations. 505 5. Contributors 507 The following people contributed to creating this document, and are 508 listed in alphabetical order: 510 Henk Birkholz 512 6. References 514 6.1. Informative References 516 [I-D.ietf-i2nsf-gap-analysis] 517 Hares, S., Moskowitz, R., and Zhang, D., "Analysis of 518 Existing work for I2NSF", draft-ietf-i2nsf-gap-analysis-02 519 (work in progress), July 2016. 521 [I-D.ietf-i2nsf-problem-and-use-cases] 522 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 523 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 524 ietf-i2nsf-problem-and-use-cases-02 (work in progress), 525 October 2016. 527 [I-D.ietf-netmod-acl-model] 528 Bogdanovic, D., Sreenivasa, K., Huang, L., Blair, D., 529 "Network Access Control List (ACL) YANG Data Model", 530 draft-ietf-netmod-acl-model-09 (work in progress), 531 October 2016. 533 [I-D.ietf-opsawg-firewalls] 534 Baker, F. and P. Hoffman, "On Firewalls in Internet 535 Security", draft-ietf-opsawg-firewalls-01 (work in 536 progress), October 2012. 538 [I-D.ietf-sacm-terminology] 539 Birkholz, H., Lu, J., Strassner, J., Cam-Wignet, N., 540 "Secure Automation and Continuous Monitoring (SACM) 541 Terminology", draft-ietf-sacm-terminology-11, 542 September 2016 544 [I-D.ietf-supa-generic-policy-info-model] 545 Strassner, J., Halpern, J., and J. Coleman, "Generic 546 Policy Information Model for Simplified Use of Policy 547 Abstractions (SUPA)", draft-ietf-supa-generic-policy- 548 info-model-01 (work in progress), July 2016. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to 554 Accounting Management", RFC 2975, DOI 10.17487/RFC2975, 555 October 2000, . 557 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 558 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 559 . 561 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and 562 Accounting (AAA) Transport Profile", RFC 3539, 563 DOI 10.17487/RFC3539, June 2003, 564 . 566 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 567 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 568 . 570 [X.1252] ITU-T, "Baseline identity management terms and 571 definitions", Recommendation ITU-T X.1252, April 2510 573 Authors' Addresses 575 Susan Hares 576 Huawei 577 7453 Hickory Hill 578 Saline, MI USA 48176 579 Phone: +1-734-604-0332 580 Email: shares@ndzh.com 582 John Strassner 583 Huawei Technologies 584 Santa Clara, CA USA 95050 585 Email: john.sc.strassner@huawei.com 587 Diego R. Lopez 588 Telefonica I+D 589 Don Ramon de la Cruz, 82 590 Madrid 28006 591 Spain 592 Email: diego.r.lopez@telefonica.com 593 Liang Xia (Frank) 594 Huawei 595 101 Software Avenue, Yuhuatai District 596 Nanjing , Jiangsu 210012 597 China 598 Email: Frank.Xialiang@huawei.com 600 Henk Birkholz 601 Fraunhofer SIT 602 Rheinstrasse 75 603 Darmstadt 64295 604 Germany 605 Email: henk.birkholz@sit.fraunhofer.de