idnits 2.17.1 draft-burbridge-lmap-information-model-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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 21, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1-12' is mentioned on line 630, but not defined == Missing Reference: 'Mon-Sun' is mentioned on line 634, but not defined == Missing Reference: '1-31' is mentioned on line 638, but not defined == Missing Reference: '1-24' is mentioned on line 642, but not defined == Missing Reference: '1-60' is mentioned on line 650, but not defined == Outdated reference: A later version (-01) exists of draft-bagnulo-ippm-new-registry-00 == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-00 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Burbridge 3 Internet-Draft P. Eardley 4 Intended status: Informational British Telecom 5 Expires: April 24, 2014 M. Bagnulo 6 Universidad Carlos III de Madrid 7 J. Schoenwaelder 8 Jacobs University 9 October 21, 2013 11 Information Model for Large-Scale Measurement Platforms (LMAP) 12 draft-burbridge-lmap-information-model-01 14 Abstract 16 This Information Model applies to the Measurement Agent within a 17 Large-Scale Measurement Platform. As such it outlines the 18 information that is (pre-)configured on the MA or exists in 19 communications with a Controller or Collector within an LMAP 20 framework. The purpose of such an Information Model is to provide a 21 protocol and device independent view of the MA that can be 22 implemented via one or more Control and Report protocols. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 19, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. LMAP Information Model . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Information Structure . . . . . . . . . . . . . . . . . . 4 66 2.2. Pre-Configuration Information . . . . . . . . . . . . . . 5 67 2.3. Configuration Information . . . . . . . . . . . . . . . . 5 68 2.4. Instruction Information . . . . . . . . . . . . . . . . . 6 69 2.5. Logging Information . . . . . . . . . . . . . . . . . . . 9 70 2.6. Status Information . . . . . . . . . . . . . . . . . . . . 10 71 2.7. Reporting Information . . . . . . . . . . . . . . . . . . 11 72 2.8. Channels . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 2.9. Timing Information . . . . . . . . . . . . . . . . . . . . 13 74 2.9.1. Periodic Timing . . . . . . . . . . . . . . . . . . . 14 75 2.9.2. Calendar Timing . . . . . . . . . . . . . . . . . . . 14 76 2.9.3. One-Off Timing . . . . . . . . . . . . . . . . . . . . 15 77 2.9.4. Immediate Timing . . . . . . . . . . . . . . . . . . . 15 78 2.9.5. Timing Randomness . . . . . . . . . . . . . . . . . . 15 79 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 82 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 A large-scale measurement platform is a collection of components that 88 work in a coordinated fashion to perform measurements from a large 89 number of vantage points. The main components of a large-scale 90 measurement platform are the Measurement Agents (hereafter MAs), the 91 Controllers and the Collectors. 93 The MAs are the elements actually performing the measurements. The 94 MAs are controlled by one or more Controllers and the Collectors 95 gather the results generated by the MAs. In a nutshell, the normal 96 operation of a large-scale measurement platform starts with the 97 Controller instructing a set of MAs to perform a set of measurements 98 at a certain point in time. The MAs execute the instructions from 99 the Controller and once they have done so they report the results of 100 the measurements to the Collector. The overall framework for a Large 101 Measurement platform and the terminology used in this document is 102 described in detail in [I-D.ietf-lmap-framework]. 104 A large-scale measurement platform involves basically three 105 protocols, namely, a Control protocol between the Controller(s) and 106 the MAs, a Report protocol between the MAs and the Collector(s) and 107 several measurement protocols between the MAs used to actually 108 perform the measurements. In addition the some information is 109 required to be provisioned to the MA prior to any comunication with 110 the Controller. 112 This document defines the information model for both the Control and 113 the Report protocol along with pre-configuration information that is 114 required before communicating with the Controller, broadly named as 115 the LMAP Information Model (or LMAP IM for short). The measurement 116 protocols are out of the scope of this document. 118 As defined in [RFC3444], the LMAP IM defines the concepts involved in 119 a large-scale measurement platform at a high level of abstraction, 120 independently of any specific implementation or actual protocol used 121 to exchange the information. It is expected that the proposed 122 information model can be used with different protocols in different 123 measurement platform architectures and across different types of MA 124 device (e.g. home gateway, smartphone, PC, router etc.). 126 2. LMAP Information Model 127 2.1. Information Structure 129 The information described herein relates to the information stored, 130 received or transmitted by a Measurement Agent as described within 131 the LMAP framework [I-D.ietf-lmap-framework]. As such, some subsets 132 of this information model are applicable to the measurement 133 Controller, Collector and systems that pre-configure the Measurement 134 Agent. The information described in these models will be transmitted 135 across the protocols and interfaces between the Measurement Agent and 136 such systems according to a Data Model. 138 For clarity the information model is divided into six sections: 140 1. Pre-Configuration Information. Information pre-configured on the 141 Measurement Agent prior to any communication with other 142 components of the LMAP architecture, specifically detailing how 143 to register with a Controller 145 2. Configuration Information. Information delivered to the MA on 146 registration with a Controller or updated during a later 147 communication, in particular detailing how to retrieve 148 measurement and reporting instruction information from a 149 Controller along with information specifically about the MA 151 3. Instruction Information. Information that is received by the MA 152 from the Controller pertaining to the measurement and reporting 153 configuration. This includes measurement configuration, report 154 channel configuration, measurement schedules and measurement 155 suppression information 157 4. Logging Information. Information transmitted from the MA to the 158 Controller detailing the results of any configuration operations 159 along with error and status information from the operation of the 160 MA 162 5. Status Information. Information on the general status and 163 capabilities of the MA. For example, the set of measurements 164 that are supported on the device 166 6. Reporting Information. Information transmitted from the MA to 167 the Collector including measurement results and the context in 168 which they were conducted 170 In addition the MA may hold further information not described herein, 171 and which may be optionally transferred to or from other systems 172 including the Controller and Collector. One example of information 173 in this category is subscriber or line information that may be 174 reported by the MA as optional fields in the reporting communication 175 to the Collector. 177 2.2. Pre-Configuration Information 179 This information is the minimal information that needs to be pre- 180 configured to the MA in order for it to successfully communicate with 181 a Controller during the registration process. 183 This pre-configuration information needs to include an URL of the 184 Controller where configuration information can be retrieved along 185 with the security information required for the communication 186 including the certificate of the Controller (or the certificate of 187 the Certification Authority which was used to issue the certificate 188 for the Controller) as well as the timing for that communication. 189 All this is expressed as the Configuration Channel. In addition to 190 the Configuration Channel information, the MA's security information 191 is configured which can be either a certificate and a private key or 192 a password, depending on the security solution used. 194 Detail of the information model elements: 196 1. MA MAC: MAC Address 198 2. Configuration Channel: Channel 200 3. MA Certificate: Certificate (optional) 202 4. MA ID: random UUID (optional) 204 5. MA password: string (optional) 206 The detail of the Channel object is described later since it is 207 common to several parts of the information model. 209 2.3. Configuration Information 211 During registration or at any later point at which the MA contacts 212 the Controller, the choice of Controller and details for the timing 213 of communication with the Controller can be changed. For example the 214 pre-configured Controller may be replaced with a specific Controller 215 that is more appropriate to the MA device type, location of 216 characteristics of the network (e.g. access technology type or 217 broadband product). The initial communication timing object may also 218 be replaced with one more relevant to routine communications between 219 the MA and the Controller. 221 In addition the MA will be given further items of information that 222 relate specifically to the MA rather than the measurements it is to 223 conduct or how to report results. The assignment of an ID to the MA 224 is mandatory. Optionally a Group ID may also be given which 225 identifies a group of interest to which that MA belongs. For example 226 the group could represent an ISP, broadband product, technology, 227 market classification, geographic region, or a combination of 228 multiple such characteristics. Where the Measurement Group ID is set 229 an additional flag (the Report MA ID flag) is required to control 230 whether the Measurement Agent ID is to be reported. This allows the 231 MA to remain anonymous which may be particularly useful to prevent 232 tracking of mobile MA devices. 234 The configuration information will also contain information about 235 different communication channels that the MA will have with different 236 elements of the infrastructure. Each channel specifies a URL, 237 security information and timing information for the communication. 239 Detail of the additional information model elements: 241 1. Measurement Agent ID: UUID 243 2. Measurement Group ID (optional): String 245 3. Report MA ID flag (optional): Boolean 247 4. Instruction Channel: Channel (DISCUSSION: shouldn't we split this 248 into 4 different channels i.e. the Measurement Task Configuration 249 channel, the Report Channel channel, the Measurement Schedules 250 channel and the Measurement Suppression channel?) 252 5. Status Channel: Channel 254 6. Logging Channel: Channel 256 2.4. Instruction Information 258 The Instruction information model has four sub-elements: 260 1. Measurement Task Configurations: Set 262 2. Report Channels: Set 264 3. Measurement Schedules: Set 266 4. Measurement Suppression: Object 268 Conceptually each Measurement Task Configuration defines the 269 parameters of a Measurement Task that the Measurement Agent (MA) may 270 perform at some point in time. It does not by itself actually 271 instruct the MA to perform them at any particular time (this is done 272 by a Measurement Schedule). 274 Example: A Measurement Task Configuration may configure a single 275 Measurement Task for measuring UDP latency. The Measurement Task 276 Configuration could define the destination port and address for 277 the measurement as well as the duration, internal packet timing 278 strategy and other parameters (for example a stream for one hour 279 and sending one packet every 500 ms). It may also define the 280 output type and possible parameters (for example the output type 281 can be the 95th percentile mean) where the measurement task 282 accepts such parameters. It does NOT define when the task starts 283 (this is defined by the Measurement Schedule element), so it does 284 not by itself instruct the MA to actually perform this measurement 285 task. 287 The Measurement Task Configuration will include a local short name 288 for reference by the Measurement Schedule, along with a registry 289 entry [I-D.bagnulo-ippm-new-registry] that defines the Measurement 290 Task. The MA itself will resolve the registry entry to a local 291 executable program. In addition the Measurement Task is specialised 292 through a set of configuration Options. The nature and number of 293 these Options will depend upon the Measurement Task and will be 294 defined in the Measurement Task Registry. In addition the 295 Measurement Task Configuration may optionally also be given a 296 Measurement Cycle ID. The purpose of this ID is to easily identify a 297 set of measurement results that have been produced by Measurement 298 Tasks with comparable Options. This ID is manually incremented when 299 an Option change is implemented which could mean that two sets of 300 results should not be directly compared. 302 A Report Channel defines how to report results to a single Collector. 303 Several Report Channels can be defined to enable results to be split 304 or duplicated across different report intervals or destinations. 305 E.g. a single Collector may have three Report Channels, one reporting 306 hourly, another reporting daily and a third on which to send 307 immediate results for on-demand measurement tasks. The details of 308 the Channel element is described later as it is common to several 309 objects. 311 A Measurement Schedule contains the instruction from the Controller 312 to the MA to execute a single or repeated series of Measurement 313 Tasks. Each Measurement Schedule contains basically three elements: 314 a reference to a list of Measurement Task Configuration, a reference 315 to a set of one or more Report Channels, and a timing object for the 316 schedule. The schedule basically states what measurement task to 317 run, how to report the results, and when to run the measurement task. 318 Multiple measurement tasks in the list will be executed in order with 319 minimal gaps. Note that the Controller can instruct the MA to report 320 to several Collectors by specifying several Report Channels. 322 Example: a Measurement Schedule references a single Measurement Task 323 Configuration for the UDP latency defined in the previous example. 324 It references the Report Channel in the previous example to send 325 results immediately as available to the specified Collector. The 326 timing is specified to run the configured Measurement Task 327 Configuration every hour at 23 minutes past the hour. 329 Measurement Suppression information is used to over-ride the 330 Measurement Schedule and stop measurements from the MA for a defined 331 or indefinite period. While conceptually measurements can be stopped 332 by simply removing them from the Measurement Schedule, splitting out 333 separate information on Measurement Suppression allows this 334 information to be updated on the MA on a different timing cycle or 335 protocol implementation to the Measurement Schedule. 337 The goal when defining these four different elements is to allow each 338 part of the information model to change without affecting the other 339 three elements. For example it is envisaged that the Report Channels 340 and the set of Measurement Tasks Configurations will be relatively 341 static. The Measurement Schedule on the other hand is likely to be 342 more dynamic as the measurement panel and test frequency are changed 343 for various business goals. Another example is that measurements can 344 be suppressed with a Measurement Suppression command without removing 345 the existing Measurement Schedules that would continue to apply after 346 the Measurement Suppression expires or is removed. In terms of the 347 Controller-MA communication this can reduce the data overhead. It 348 also encourages the re-use of the same standard Measurement Task 349 Configurations and Reporting Channels to help ensure consistency and 350 reduce errors. 352 Definition of the information model elements: 354 1. Measurement Task Configurations: Set 356 1. Measurement Task Configuration: Object 358 1. Task Name (used for referral from the Measurement 359 Schedules): String 361 2. Registry Entry: URN 363 3. Options: Set (optional) 365 1. Interface name (reference by name to one of the 366 Interfaces defined in the Status information): String 368 4. Measurement Cycle ID: String (optional) 370 2. Report Channels: Set 372 1. Report Channel: Channel 374 3. Measurement Schedules: Set 376 1. Measurement Schedule: Object 378 1. Schedule Name: String 380 2. Measurement Task Configuration Names (reference by Name 381 to one of the measurement tasks defined in the 382 Measurement Task Configuration set): List 384 1. Task Name: String 386 3. Report Channel Names (reference by Name to one of the 387 measurement tasks defined in the Measurement Task 388 Configuration set): Set 390 1. Channel Name: String 392 4. Measurement Timing: Timing 394 4. Measurement Suppression: Object (optional) 396 1. Start: datetime 398 2. End: datetime 400 3. Set of Measurement Task Configuration Names (optional - 401 default all) 403 1. Task Name: String 405 2.5. Logging Information 407 The MA will report back success/failure and status information to the 408 Controller. These messages will fall into a number of different 409 categories: 411 1. Success/failure messages in response to information updates from 412 the Controller. For example: 414 * "Report Channel 'hourly db" configured" 415 * "Measurement Schedule does not conform to schema, Row 211" 417 2. Status updates from the operation of the MA. For example: 419 * "out of memory: cannot record result" 421 * "Collector 'collector.example.com' not responding" 423 Each log message will have the following Information model elements: 425 1. Log Time: datetime 427 2. Log Event: Object 429 2.6. Status Information 431 In addition to the information reported by the MA through the logging 432 information, the MA will hold further status information that can be 433 retrieved by a Controller. One category of additional information 434 that has not been defined in earlier sections is the availability of 435 Measurement Tasks on that MA. 437 MA Status information model elements: 439 1. MA ID: String 441 2. MA Device: String 443 3. MA hardware: String (optional) 445 4. MA firmware: String (optional) 447 5. MA software: String (optional) 449 6. MA Interfaces: set 451 1. If name: String 453 2. If type: String (one of eth, wlan, TBC) 455 3. If speed: Integer (expressed in Mbps) 457 4. Link Layer Address: String 459 5. IP address: Set 461 1. Protocol: String (one of v4, v6) 462 2. Address: String 464 6. Gateway: Set (optional) 466 1. Protocol: String (one of v4, v6) 468 2. Address: String 470 7. DNS server: Set (optional) 472 1. Protocol: String (one of v4, v6) 474 2. Address: String 476 7. Last Measurement: datetime 478 8. Last Report: datetime 480 9. Last Instruction: datetime 482 10. Last Configuration: datetime 484 11. Supported Measurements: Set 486 1. Registry Entry: URN 488 2. Version: String (optional) 490 2.7. Reporting Information 492 At a point in time specific by the Report Channel, the MA will 493 communicate a set of measurement results to the Collector. These 494 measurement results should be communicated within the context in 495 which they were collected. 497 The report is structured hierarchically to avoid repetition of 498 report, Measurement Agent and Measurement Task Configuration 499 information. The report starts with the timestamp of the report 500 generation on the MA and details about the MA including the optional 501 Measurement Agent ID and Group ID (controlled by the Configuration 502 Information). In addition optional further MA context information 503 can be included at this point such as the line sync speed or ISP and 504 product if known by the MA. 506 After the MA information the results are reported grouped into the 507 different Measurement Tasks. Each Task starts with replicating the 508 Measurement Task Configuration information before the result headers 509 (titiles for data columns) and the result data rows. 511 Information model elements: 513 1. Report Date: datetime 515 2. Measurement Agent ID: String (optional) 517 3. Measurement Group ID: String (optional) 519 4. MA Context: Set (optional) 521 1. Context Item: Object 523 5. Measurement Task: Set 525 1. Measurement Task Configuration: Object 527 2. Result Headers: List 529 1. Column Name: String 531 3. Result Data: List 533 1. Result Row: Object 535 1. Measurement Time: datetime 537 2. Cross-traffic: Integer (optional) 539 3. Result Columns: List 541 1. Column Data 543 2.8. Channels 545 A Channel defines a communication channel between the MA and other 546 element of the measurement framework i.e. with the Collector to 547 report results back, to Controller to retrieve Instructions or other 548 information exchanged between the parties. Several Channels can be 549 defined to enable results to be split or duplicated across different 550 report intervals or destinations. E.g. a single Collector may have 551 three Report Channels, one reporting hourly, another reporting daily 552 and a third on which to send immediate results for on-demand 553 measurement tasks. 555 Each Channel contains the details of the target (including location 556 and security information such as the certificate), and the timing for 557 the communication i.e. when to establish the communication. The 558 certificate can be the digital certificate associated to the FQDN in 559 the URL or it can be the certificate of the Certification Authority 560 that was used to issue the certificate for the FQDN of the target URL 561 (which will be retrieved later on using a communication protocol such 562 as SSL). The Channel can use the same timing information object as a 563 Measurement Schedule and the Controller Communication Timing defined 564 earlier. There are several options, such as immediately after the 565 results are obtained or at a given interval or calendar based cycle). 566 As with the Measurement task Configuration, each Channel is also 567 given a local short name by which it can be referenced from a 568 Measurement Schedule or other elements. 570 Example: A Channel using for reporting results may specify that 571 results are to be sent to the URL 572 (https://collector.foo.org/report/), using the appropriate digital 573 certificate to establish a secure channel. The Channel specifies 574 that the results are to be sent immediately as available and not 575 batched. 577 Channel: Object 579 1. Channel Name (used for referral from other objects ): String 581 2. Target: URL 583 3. Certificate: X.509 Certificate 585 4. Communication Timing: Timing 587 2.9. Timing Information 589 The Timing information object used throughput the information models 590 can take one of four different forms: 592 1. Periodic. Specifies a start, end and interval time in 593 milliseconds 595 2. Calendar: Specifies a calendar based pattern - e.g. 22 minutes 596 past each hour of the day on weekdays 598 3. One Off: A single instance occurring at a specific time 600 4. Immediate: Should occur as soon as possible 602 Optionally each of the first three options may also specify a 603 randomness that should be evaluated and applied separately to each 604 indicated event. 606 2.9.1. Periodic Timing 608 Information model elements: 610 1. 1. Timing Name: String 612 2. 2. Start: datetime (optional) 614 3. 3. End: datetime (optional) 616 4. 4. Interval: Integer (in milliseconds) 618 5. 5. Randomness: Timing Randomness (optional) 620 2.9.2. Calendar Timing 622 Information model elements: 624 1. Timing Name: String 626 2. Start: datetime (optional) 628 3. End: datetime (optional) 630 4. Months: Set (optional - default [1-12]) 632 1. Month: Integer 634 5. Weekdays: Set (optional - default [Mon-Sun]) 636 1. Weekday: String (one off Mon, Tue, Wed, Thu, Fri, Sat Sun) 638 6. Days: Set (optional - default [1-31]) 640 1. Day: Integer 642 7. Hours: Set (optional - default [1-24]) 644 1. Hour:Integer 646 8. Minutes: Set (optional - default [1-60]) 648 1. Minute: Integer 650 9. Seconds: Set (optional - default [1-60]) 652 1. Second: Integer 654 10. Randomness: Timing Randomness (optional) 656 2.9.3. One-Off Timing 658 Information model elements: 660 1. Time: datetime 662 2. Randomness: Timing Randomness (optional) 664 2.9.4. Immediate Timing 666 The immediate timing object has no further information elements. The 667 measurement or report is simply to be done as soon as possible. 669 2.9.5. Timing Randomness 671 The Timing randomness object specifies a random distribution that can 672 be applied to any scheduled execution event such as a measurement or 673 report. The intention it to be able to spread the load on the 674 Controller, Collector and network in an automated manner for a large 675 number of Measurement Agents. The randomness is expressed as a 676 distribution (e.g. Poison, Normal, Uniform etc.) along with the 677 spread over which the distribution should be applied. In additional 678 optional upper and lower bounds can be applied to control extreme 679 spread of timings. 681 Information model elements: 683 1. Distribution: String 685 2. Upper Cut: Integer (optional) 687 3. Lower Cut: Integer (optional) 689 4. Spread: Integer 691 3. IANA Considerations 693 This document makes no request of IANA . 695 Note to RFC Editor: this section may be removed on publication as an 696 RFC. 698 4. Security Considerations 700 This Information Model deals with information about the control and 701 reporting of the Measurement Agent. There are broadly two security 702 considerations for such an Information Model. Firstly the 703 Information Model has to be sufficient to establish secure 704 communication channels to the Controller and Collector such that 705 other information can be sent and received securely. The second 706 consideration is that no mandated information items pose a risk to 707 confidentiality or privacy given such secure communication channels. 708 For this latter reason items such as the MA context and MA ID are 709 left optional and can be excluded from some deployments. This would, 710 for example, allow the MA to remain anonymous and for information 711 about location or other context that might be used to identify or 712 track the MA to be ommitted or blurred. 714 5. Acknowledgements 716 6. Informative References 718 [I-D.bagnulo-ippm-new-registry] 719 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 720 A. Morton, "A registry for commonly used metrics", 721 draft-bagnulo-ippm-new-registry-00 (work in progress), 722 January 2013. 724 [I-D.ietf-lmap-framework] 725 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 726 Aitken, P., and A. Akhter, "A framework for large-scale 727 measurement platforms (LMAP)", 728 draft-ietf-lmap-framework-00 (work in progress), 729 October 2013. 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, March 1997. 734 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 735 Information Models and Data Models", RFC 3444, 736 January 2003. 738 Authors' Addresses 740 Trevor Burbridge 741 British Telecom 742 Adastral Park, Martlesham Heath 743 Ipswich, IP5 3RE 744 UK 746 Phone: 747 Fax: 748 Email: 749 URI: 751 Philip Eardley 752 British Telecom 753 Adastral Park, Martlesham Heath 754 Ipswich, IP5 3RE 755 UK 757 Phone: 758 Fax: 759 Email: 760 URI: 762 Marcelo Bagnulo 763 Universidad Carlos III de Madrid 764 Av. Universidad 30 765 Leganes, Madrid, 28911 767 Phone: 768 Fax: 769 Email: 770 URI: 772 Juergen Schoenwaelder 773 Jacobs University 775 Phone: 776 Fax: 777 Email: 778 URI: