idnits 2.17.1 draft-kumar-i2nsf-client-facing-interface-im-00.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 document seems to lack a Security Considerations section. ** The abstract seems to contain references ([I-D.kumar-i2nsf-client-facing-interface-req]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 168: '...he domain object SHALL have following ...' RFC 2119 keyword, line 189: '...he tenant object SHALL have the follow...' RFC 2119 keyword, line 205: '... The role object SHALL have following ...' RFC 2119 keyword, line 223: '... The user object SHALL have following ...' RFC 2119 keyword, line 247: '... This object SHALL have following in...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2016) is 2726 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-i2nsf-terminology' is defined on line 712, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-i2nsf-problem-and-use-cases-02 == Outdated reference: A later version (-08) exists of draft-ietf-i2nsf-terminology-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF Working Group R. Kumar 3 Internet-Draft A. Lohiya 4 Intended status: Informational Juniper Networks 5 Expires: May 4, 2017 D. Qi 6 Bloomberg 7 N. Bitar 8 S. Palislamovic 9 Nokia 10 L. Xia 11 Huawei 12 October 31, 2016 14 Information model for Client-Facing Interface to Security Controller 15 draft-kumar-i2nsf-client-facing-interface-im-00 17 Abstract 19 This document defines information model for the client-facing 20 interface to security controller based on the requirements identfied 21 in the [I-D.kumar-i2nsf-client-facing-interface-req]. The 22 information model defines various managed objects and the 23 relationship among these objects needed to build the client 24 interfaces. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 62 3. Information Model for Multi Tenancy . . . . . . . . . . . . . 4 63 3.1. Policy-Domain . . . . . . . . . . . . . . . . . . . . . . 4 64 3.2. Policy-Tenant . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Policy-Role . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Policy-User . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.5. Policy-Management-Authentication-method . . . . . . . . . 6 68 4. Information Model for Policy Endpoint Groups . . . . . . . . 6 69 4.1. Meta Data Source . . . . . . . . . . . . . . . . . . . . 7 70 4.2. User-Group . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Device-Group . . . . . . . . . . . . . . . . . . . . . . 8 72 4.4. Application-Group . . . . . . . . . . . . . . . . . . . . 8 73 4.5. Location-Group . . . . . . . . . . . . . . . . . . . . . 9 74 5. Information Model for Threat Prevention . . . . . . . . . . . 9 75 5.1. Threat-Feed . . . . . . . . . . . . . . . . . . . . . . . 9 76 5.2. Custom-List . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.3. Malware-Scan-Group . . . . . . . . . . . . . . . . . . . 10 78 5.4. Event-Map-Group . . . . . . . . . . . . . . . . . . . . . 11 79 6. Information Model for Telemetry Data . . . . . . . . . . . . 11 80 6.1. Telemetry-Data . . . . . . . . . . . . . . . . . . . . . 11 81 6.2. Telemetry-Source . . . . . . . . . . . . . . . . . . . . 12 82 6.3. Telemetry-Destination . . . . . . . . . . . . . . . . . . 12 83 7. Information Model for Policy Instance . . . . . . . . . . . . 13 84 7.1. Policy-Calendar . . . . . . . . . . . . . . . . . . . . . 13 85 7.2. Policy-Action . . . . . . . . . . . . . . . . . . . . . . 14 86 7.3. Policy-Rule . . . . . . . . . . . . . . . . . . . . . . . 14 87 7.4. Policy-Instance . . . . . . . . . . . . . . . . . . . . . 15 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 10. Informative References . . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 The security controller's client-facing interfaces would be built 96 using a set of objects, with each object capturing a unique set of 97 information from security admin. The objects may have relationship 98 with other objects to express complete requirement. An information 99 model captures the managed objects and relationship among these. The 100 information model proposed in this draft is in accordance with the 101 client interface requirements as defined in 102 [I-D.kumar-i2nsf-client-facing-interface-req]. 104 The [RFC3444] explains the difference between information and data 105 model. This draft use those guidlines to define the information 106 model in this draft. A data model, that represents an implementation 107 of this proposed information model in a specific data representation 108 language, will be defined in a separate draft. 110 2. Conventions Used in this Document 112 BSS: Business Support System 114 CLI: Command Line Interface 116 CMDB: Configuration Management Database 118 Controller: Used interchangeably with Service Provider Security 119 Controller or management system throughout this document 121 CRUD: Create, Retrieve, Update, Delete 123 FW: Firewall 125 GUI: Graphical User Interface 127 IDS: Intrusion Detection System 129 IPS: Intrusion Protection System 131 LDAP: Lightweight Directory Access Protocol 133 NSF: Network Security Function, defined by 134 [I-D.ietf-i2nsf-problem-and-use-cases] 136 OSS: Operation Support System 138 RBAC: Role Based Access Control 140 SIEM: Security Information and Event Management 141 URL: Universal Resource Locator 143 vNSF: Refers to NSF being instantiated on Virtual Machines 145 3. Information Model for Multi Tenancy 147 The multi-tenancy is an important aspect of any application that 148 enables multiple administrative domains for managing the application 149 resources. An oganization may have multiple tenants or departments 150 such as HR, Finance, Legal, with each tenant having a need to manage 151 its own security policies. 153 There are multiple managed objects that constitute multi-tenancy 154 aspects. This section lists these objects and any relationship among 155 these objects. 157 3.1. Policy-Domain 159 This object defines an oragnization boundary for the purpose of 160 policy management. This may vary based on how security controller is 161 deployed and hosted. For example, if an Enterprise host a security 162 controller in their network; the domain in this case could just be 163 the one that reperesents that Enterprise. But if a cloud service 164 provider host managed services, then a domain could represent a 165 single customer of the service provider. The multi-tenancy model 166 should be applicable in all such environments. 168 The domain object SHALL have following infomation: 170 Name: Name of the organization or customer representing this domain 172 Address: Address of the organization or customer 174 Contact: Contact information of the organization or customer 176 Date: Date this account was created or last modified 178 Authentication Method: Authentication method to be used for this 179 domain. It should be reference to a 'policy-management-auth- 180 method' object 182 3.2. Policy-Tenant 184 This object defines an entity within an organization that wants to 185 manage its own security posture. The entity could be a department or 186 a division that manages its own security policies due to regulatory 187 compliance or organizational structure. 189 The tenant object SHALL have the following information: 191 Name: Name of the department or division within an organization 193 Date: Date this account was created or last modified 195 Domain: This field identifies the domain to which this tenent 196 belongs. This should be reference to a 'policy-domain' object 198 3.3. Policy-Role 200 This object defines a set of permissions assigned to a user in an 201 organization that want to manage its own security posture. It 202 provides a convenient way to assign policy users to a job function or 203 set of permissions within the organization. 205 The role object SHALL have following information: 207 Name: This field identifies the name of the role 209 Date: Date this role was created or last modified 211 Access Profile: This field identifies the access profile for the 212 role. The profile grants or denies access to policy objects. 213 Multiple access profiles can be concatenated together 215 3.4. Policy-User 217 This object represents a unique identity within an organization. 218 This identity authenticates with the security controller using 219 credentials such as a password or token in order to do policy 220 management. A user may be an individual, system, or application 221 requiring access to security controller. 223 The user object SHALL have following information: 225 Name: Name of the user 227 Date: Date this user was created or last modified 229 Password: User password for basic authentication 231 Email: E-mail address of the user 233 Scope Type: This field identifies whether the user has domain-wide 234 or tenent-wide privileges 236 Scope Reference: This field should be reference to either a 'policy- 237 domain' or a 'policy-tenant' object 239 Role: This field should be reference to a 'policy-role' object that 240 defines the specific permissions 242 3.5. Policy-Management-Authentication-method 244 This object represents authentication schemes supported by security 245 controller. 247 This object SHALL have following information: 249 Name: This field identifies the name of this object 251 Date: Date this object was created or last modified 253 Authentication Method: This field identifies the authentication 254 methods. It could be a password based, token based, certificate 255 based or single sign-on authentication 257 Mutual Authentication: This field indicates whether mutual 258 authentication is mandatory or not 260 Token Server: This field stores the information about server that 261 validates the token submitted as credentials 263 Certificate Server: This field stores the infromation about server 264 that validates certificates submitted as credentials 266 Single Sign-on Server: This field stores the infromation about 267 server that validates user credentials 269 4. Information Model for Policy Endpoint Groups 271 The policy endpoint groups are very important part of building user- 272 construct policy. The security admins could use these objects to 273 represent a logical entity in their business enviroment, where a 274 security policy is to be applied. 276 There are multiple managed objects that constitute policy endpoint 277 groups. This section lists these objects and relationship among 278 these objects. 280 4.1. Meta Data Source 282 This object represents information source for the meta-data or tag. 283 The meta-data in a group must be mapped to corresponding contents to 284 enforce a security policy. 286 The meta data source object SHALL have following information: 288 Name: This field identifies the name of this object 290 Date: Date this object was created or last modified 292 Tag Type: This field identifies the Endpoint group type. It can be 293 either a 'User' group or 'App' group or 'Device' group, or 294 'Location' group based policy 296 Tag Server Information: This field identifies the information 297 related to the source of the tag such as IP address and UDP/TCP 298 port information 300 Tag Application Protocol: This filed identifies the protocol e.g. 301 LDAP, Active Directory, or CMDB 303 Tag Server Credentials: This field identifies the credential 304 information needed to access the tag server 306 4.2. User-Group 308 This object represents a user group based on either tag or other 309 information. 311 The user-group object SHALL have following information: 313 Name: This field identifies the name of this object 315 Date: Date this object was created or last modified 317 Group Type: This field identifies whether the user group is based 318 on 'User-tag', 'User-names', or 'IP-addresses' 320 Meta-data Server: This field should be reference to a 'meta-data- 321 source' object 323 Group Member: This field is the 'User-tag, or 'User-names', or IP 324 addresses based on the 'Group Type' 326 Risk Level: This field represents the threat level; valid range may 327 be 0 to 9 329 4.3. Device-Group 331 This object represents a device group based on either tag or other 332 information. 334 The device-group object SHALL have following information: 336 Name: This field identifies the name of this object 338 Date: Date this object was created or last modified 340 Group Type: This field identifies whether the device group is based 341 on 'Device-tag' or 'Device-names', or IP addresses 343 Meta-data Server: This field should be reference to a 'meta-data- 344 source' object 346 Group Member: This field is the 'Device-tag, or 'Device-names', or 347 IP addresses based on the 'Group Type' 349 Risk Level: This field represents the threat level; valid range may 350 be 0 to 9 352 4.4. Application-Group 354 This object represents an application group based on either tag or 355 other information. 357 The application-group object SHALL have following information: 359 Name: This field identifies the name of this object 361 Date: Date this object was created or last modified 363 Group Type: This field identifies whether the device group is based 364 on 'App-tag' or 'App-names', or IP addresses 366 Meta-data Server: This field should be reference to a 'meta-data- 367 source' object 369 Group Member: This field is the 'Device-tag, or 'Device-names', or 370 IP addresses and port information based on the 'Group Type' 372 Risk Level: This field represents the threat level; valid range may 373 be 0 to 9 375 4.5. Location-Group 377 This object represents an location group based on either tag or other 378 information. 380 The location-group object SHALL have following information: 382 Name: This field identifies the name of this object 384 Date: Date this object was created or last modified 386 Group Type: This field identifies whether the location group is 387 based on 'Location-tag' or 'Location-names', or IP addresses 389 Meta-data Server: This field should be reference to a 'meta-data- 390 source' object 392 Group Member: This field is the 'Location-tag, or 'Location-names', 393 or IP addresses based on the 'Group Type' 395 Risk Level: This field represents the threat level; valid range may 396 be 0 to 9 398 5. Information Model for Threat Prevention 400 The threat prevention plays an important part in the overall security 401 posture by reducing the attack surface. This information could come 402 in the form of threat feeds such as Botnet, GeoIP usually from a 403 third party or external service. 405 There are multiple managed objects that constitute this category. 406 This section lists these objects and relationship among these 407 objects. 409 5.1. Threat-Feed 411 This object represents threat feed such as Botnet servers and GeoIP. 413 The threat-feed object SHALL have following information: 415 Name: This field identifies the name of this object 417 Date: Date this object was created or last modified 419 Feed Type: This field identifies whether a feed type is IP address 420 based or URL based. 422 Feed Server: This field identifies the information about the feed 423 provider, it may be an external service or local server 425 Feed Priority: This field represents the feed priority level to 426 resolve conflict if there are multiple feed sources; valid range 427 may be 0 to 9 429 5.2. Custom-List 431 This object represents custom list created for the purpose of 432 defining exception to threat feeds. An organization may want to 433 allow certain exception to threat feeds obtained from a third party 435 The custom-list object SHALL have following information: 437 Name: This field identifies the name of this object 439 Date: Date this object was created or last modified 441 List Type: This field identifies whether the list type is IP address 442 based or URL based. 444 List Property: This field identifies the attributes of the list 445 property e.g. Blacklist or Whitelist. 447 List Content: This field contains the blacklist or whitelist 448 contents such as IP addresses or URL names. 450 5.3. Malware-Scan-Group 452 This object represents information needed to detect malware. This 453 information could come from a local server or uploaded periodically 454 from third party. 456 The malware-scan-group object SHALL have following information: 458 Name: This field identifies the name of this object 460 Date: Date this object was created or last modified 462 Signature Server: This field contains information about the server 463 from where signatures can be downloaded periodically as updates 464 become available 466 File Types: This field contains list of file types needed to be 467 scanned for the virus 469 Malware Signatures: This field contains list of malware signatures 470 or hash 472 5.4. Event-Map-Group 474 This object represents an event map containing security events and 475 threat levels used for dyanmic policy enforcement. 477 The event-map-group object SHALL have following information: 479 Name: This field identifies the name of this object 481 Date: Date this object was created or last modified 483 Secuirty Events: This contains a list of security events 485 Threat Map: This contains a list of threat levels 487 6. Information Model for Telemetry Data 489 Telemetry provides visibility into the network activities which can 490 be tapped for further security analytics e.g. detecting potential 491 vulnerabilities, malicious activities etc. 493 6.1. Telemetry-Data 495 This object contains information collected for telemetry. 497 The telemetry-data object SHALL have following information: 499 Name: This field identifies the name of this object 501 Date: Date this object was created or last modified 503 Logs: This field identifies whether 'Logs' need to be collected 505 Syslogs This field identifies whether 'Syslogs' need to be collected 507 SNMP: This field identifies whether 'SNMP traps' and 'SNMP alarms' 508 need to be collected 510 sFlow: This field identifies whether 'sFlow' data need to be 511 collected 513 NetFlow: This field identifies whether 'NetFlow' data need to be 514 collected 516 Interface Stats: This field identifies whether 'Interface' data such 517 as packet bytes and counts need to be collected 519 6.2. Telemetry-Source 521 This object contains information related to telemetry source. The 522 source would be a NSF element in the network. 524 The telemetry-source object SHALL have following information: 526 Name: This field identifies the name of this object 528 Date: Date this object was created or last modified 530 Source Type: This field contains type of the NSF telemetry source: 531 "NETWORK-NSF", "FIREWALL-NSF", "IDS-NSF", "IPS-NSF", "PROXY-NSF", 532 "VPN-NSF", "DNS", "ACTIVE-DIRECTORY","IP Reputation Authority", 533 "Web Reputation Authority", "Anti-Malware Sandbox", "Honey Pot", 534 "DHCP", "Other Third Party", "ENDPOINT" 536 NSF Access Parameters: This field contains information such as IP 537 address and protocol (UDP or TCP) port number of the NSF providing 538 telemetry data 540 NSF Access Credentials: This field contains username and passwod to 541 authenticate with the NSF 543 Collection Interval: This field contains time in milliseconds 544 between data collections. For example, value of 5000 means data 545 is streamed to collector every 5 seconds. Value of 0 means data 546 streaming is event-based. 548 Collection Method: This field contains method of collection whether 549 it is PUSH-based or PULL-based 551 Heartbeat Interval: This field contains time in seconds the source 552 must send telemetry heartbeat 554 QoS Marking: This field contains DSCP value source MUST mark on its 555 generated telemetry packets 557 6.3. Telemetry-Destination 559 This object contains information related to telemetry destination. 560 The destination is usually a collector which is either a part of 561 security controller or external system such as SIEM. 563 The telemetry-destination object SHALL have following information: 565 Name: This field identifies the name of this object 567 Date: Date this object was created or last modified 569 Collector State: This field contains the state info regarding the 570 collector 572 Collector Access Parameter: This field contains the infromation such 573 as IP address and protocol (UDP or TCP) port number for the 574 collector's destination 576 Collector Access Credentials: This field contains the username and 577 passwod for the collector 579 Data Encoding: This field contains the telemetry data encoding, 580 which could in the form of a schema 582 Data Transport: This field contains streaming telemetry data 583 protocols: whether it is gRPC, protocol buffer over UDP, etc. 585 7. Information Model for Policy Instance 587 In order to enforce a security policy, a policy instance must have 588 complete information such as where and when a policy need to be 589 applied. The policy instantination is done by combining the managed 590 objects described so far and a few others listed below. 592 7.1. Policy-Calendar 594 This object contains information related to scheduling a policy. The 595 policy could be activated based on a time calendar or security event 596 including threat level changes. 598 The Policy Calendar object SHALL have following information: 600 Name: This field identifies the name of this object 602 Date: Date this object was created or last modified 604 Enforecment Type: This field identifies whether the policy 605 enforcement is 'ADMIN-ENFORCED' or 'TIME-ENFORCED', or 'EVENT- 606 ENFORCED' 608 Time Information: This field contains time calendar such as 'BEGIN- 609 TIME' and 'END-TIME' for one time enforcement or recurring time 610 calendar for periodic enforcement 612 Event Map: This field contains security events and threat map when 613 this policy need to be activated 615 7.2. Policy-Action 617 This object represents actions that a security admin want to perform 618 based on certain traffic class. 620 The action object SHALL have following information: 622 Name: This field identifies the name of this object 624 Date: Date this object was created or last modified 626 Primary Action: This field identifies the action when a policy rule 627 is matched by NSF. The action could be one of 'PERMIT', 'DENY', 628 'RATE-LIMIT', 'TRAFFIC-CLASS', 'AUTHENTICATE-SESSION', 'IPS, 'APP- 629 FIREWALL' 631 Secondary Action: The security admin can also specify additional 632 action if a rule is matched. This could be one of 'LOG', 633 'SYSLOG', 'SESSION-LOG' 635 7.3. Policy-Rule 637 This object represents rules that a security admin want to define in 638 order to express its business objectives through a security policy. 640 The policy-rule object SHALL have following information: 642 Name: This field identifies the name of this object 644 Date: Date this object was created or last modified 646 Source: This field identfies the source of the traffic. This could 647 be reference to either 'Policy Endpoint Group' or 'threat-feed' or 648 'custom-list' if security admin wants to specify the source 649 otherwise the default is to match all traffic 651 Destination: This field identfies the destination of the traffic. 652 This could be reference to either 'Policy Endpoint Group' or 653 'threat-feed' or 'custom-list' if security admin wants to specify 654 the destination otherwise the default is to match all traffic 656 Exception: This field identifies the exception consideration when 657 'Source' and 'Destination' are matched for a given communication. 658 This should be reference to 'Policy Endpoint Group' object 660 Action: This field identifies the action taken when 'Source' and 661 'Destination' are matched for a given communication 663 Precedence: This field identifies the precedence assigned to this 664 rule by security admin. This is helpful in conflict resolution 665 when two or more rules match a given traffic class 667 7.4. Policy-Instance 669 This object represents a security policy expressed by security admin 670 that would be taken by security controller and enforced on NSF as per 671 the instructions specfied in policy instance. 673 The policy-instance object SHALL have following information: 675 Name: This field identifies the name of this object 677 Date: Date this object was created or last modified 679 Rules: This field contains list of rules. If the rule does not have 680 a user defined precedence, then any conflict must be manually 681 resolved 683 Scheduling Type: This field specifies when this policy should be 684 scheduled. The policy could be scheduled based on time calendar 685 or event-map 687 Scheduling Information: This field contanins either the 'Calendar' 688 or 'Event-map' based on 'Schedule type' 690 Owner: This field defines the owner of this policy. Only the owner 691 is authrozied to modify the the contents of the policy 693 8. IANA Considerations 695 This document requires no IANA actions. RFC Editor: Please remove 696 this section before publication. 698 9. Acknowledgements 700 The authors would like to thank Kunal Modasiya, Prakash T. Sehsadri 701 and Srinivas Nimmagadda from Juniper Networks for helpful 702 discussions. 704 10. Informative References 706 [I-D.ietf-i2nsf-problem-and-use-cases] 707 Hares, S., Dunbar, L., Lopez, D., Zarny, M., and C. 708 Jacquenet, "I2NSF Problem Statement and Use cases", draft- 709 ietf-i2nsf-problem-and-use-cases-02 (work in progress), 710 October 2016. 712 [I-D.ietf-i2nsf-terminology] 713 Hares, S., Strassner, J., Lopez, D., Xia, L., and H. 714 Birkholz, "Interface to Network Security Functions (I2NSF) 715 Terminology", draft-ietf-i2nsf-terminology-02 (work in 716 progress), October 2016. 718 [I-D.kumar-i2nsf-client-facing-interface-req] 719 Kumar, R., Lohiya, A., Qi, D., Bitar, N., Palislamovic, 720 S., and L. Xia, "Requirements for Client-Facing Interface 721 to Security Controller", draft-kumar-i2nsf-client-facing- 722 interface-req-02 (work in progress), October 2016. 724 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 725 Information Models and Data Models", RFC 3444, 726 DOI 10.17487/RFC3444, January 2003, 727 . 729 Authors' Addresses 731 Rakesh Kumar 732 Juniper Networks 733 1133 Innovation Way 734 Sunnyvale, CA 94089 735 US 737 Email: rkkumar@juniper.net 739 Anil Lohiya 740 Juniper Networks 741 1133 Innovation Way 742 Sunnyvale, CA 94089 743 US 745 Email: alohiya@juniper.net 746 Dave Qi 747 Bloomberg 748 731 Lexington Avenue 749 New York, NY 10022 750 US 752 Email: DQI@bloomberg.net 754 Nabil Bitar 755 Nokia 756 755 Ravendale Drive 757 Mountain View, CA 94043 758 US 760 Email: nabil.bitar@nokia.com 762 Senad Palislamovic 763 Nokia 764 755 Ravendale Drive 765 Mountain View, CA 94043 766 US 768 Email: senad.palislamovic@nokia.com 770 Liang Xia 771 Huawei 772 101 Software Avenue 773 Nanjing, Jiangsu 210012 774 China 776 Email: Frank.Xialiang@huawei.com