idnits 2.17.1 draft-caufield-paws-protocol-for-tvws-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 : ---------------------------------------------------------------------------- ** There are 75 instances of too long lines in the document, the longest one being 30 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 551 -- Looks like a reference, but probably isn't: '360' on line 551 ** Obsolete normative reference: RFC 2426 (Obsoleted by RFC 6350) == Outdated reference: A later version (-15) exists of draft-ietf-paws-problem-stmt-usecases-rqmts-00 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PAWS J. Caufield 3 Internet-Draft Key Bridge 4 Intended status: Experimental October 31, 2011 5 Expires: May 3, 2012 7 Protocol to query a White Space Database 8 draft-caufield-paws-protocol-for-tvws-01.txt 10 Abstract 12 Regulatory entities in many countries are making spectrum previously 13 used by television stations available for secondary use as a result 14 of the switch from analog to digital. The spectrum in such cases is 15 still owned by the primary user to whom it is licensed. However 16 parts of the spectrum may be unused at a given location or time and 17 hence can be made available for secondary use. In order to use such 18 spectrum a device has to query a database in order to obtain a list 19 of available channels or spectrum at a given location and time. This 20 document specifies protocol elements that can be used to query a 21 white space database and obtain a response by a device. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 3, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 59 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Protocol approach . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Data Model details . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. White Space Query Object . . . . . . . . . . . . . . . . . 5 64 6.1.1. Query object definition . . . . . . . . . . . . . . . 5 65 6.2. White Space Response Object . . . . . . . . . . . . . . . 6 66 6.2.1. Response Object Definition . . . . . . . . . . . . . . 6 67 6.3. Elements of the Query and Response objects . . . . . . . . 7 68 6.3.1. Station element . . . . . . . . . . . . . . . . . . . 7 69 6.3.2. Schedule element . . . . . . . . . . . . . . . . . . . 7 70 6.3.3. ChannelList element . . . . . . . . . . . . . . . . . 8 71 6.3.4. ContactList element . . . . . . . . . . . . . . . . . 8 72 6.3.5. Location element . . . . . . . . . . . . . . . . . . . 8 73 6.3.6. Antenna element . . . . . . . . . . . . . . . . . . . 8 74 6.3.7. StationRxList element . . . . . . . . . . . . . . . . 9 75 6.3.8. TransmitterList element . . . . . . . . . . . . . . . 9 76 6.3.9. Address element . . . . . . . . . . . . . . . . . . . 9 77 6.3.10. Coordinate element . . . . . . . . . . . . . . . . . . 10 78 6.3.11. RadiationPattern element . . . . . . . . . . . . . . . 10 79 6.3.12. Contact Element . . . . . . . . . . . . . . . . . . . 10 80 6.3.13. Extension element . . . . . . . . . . . . . . . . . . 10 81 6.3.14. WhiteSpaceFrequencyList element . . . . . . . . . . . 11 82 6.3.15. WhiteSpaceFrequency element . . . . . . . . . . . . . 11 83 6.3.16. Channel Element . . . . . . . . . . . . . . . . . . . 11 84 6.3.17. Transmitter Element . . . . . . . . . . . . . . . . . 12 85 6.4. Attributes definition . . . . . . . . . . . . . . . . . . 13 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 1. Introduction 96 Regulatory entities in many countries are making spectrum previously 97 used by television stations available for secondary use as a result 98 of the switch from analog to digital. The spectrum in such cases is 99 still owned by the primary user to whom it is licensed. However 100 parts of the spectrum may be unused at a given location or time and 101 hence can be made available for secondary use. In order to use such 102 spectrum a device has to query a database in order to obtain a list 103 of available channels or spectrum at a given location and time. This 104 document specifies protocol elements that can be used to query a 105 white space database and obtain a response by a device. 107 The problem statement, use cases and requirements for the use of 108 white space spectrum and the associated protocol is captured in the 109 document: [I-D.ietf-paws-problem-stmt-usecases-rqmts]. 111 2. Terminology and Abbreviations 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 This document relies on the terminology specified in 118 [I-D.ietf-paws-problem-stmt-usecases-rqmts]. 120 3. Background 122 Spectrum is a scarce resource and hence it is essential that 123 technology provide a means to use this resource in an optimal manner. 124 Spectrum has been generally licensed or granted or reserved for 125 specific use by regulatory bodies and governments. Some spectrum 126 such as the ISM band has been made publicly available for use without 127 any licenses but still with a set of regulations. In many cases 128 spectrum that has been licensed to an entity or reserved is either 129 not utilized or under utilized. As the demand for services over 130 wireless medium continues to grow the need for additional spectrum is 131 increasing. Cognitive radio and white space technology is a solution 132 that allows the use of spectrum by a secondary user at a given 133 location if the primary user is either not using the spectrum at a 134 given time and without causing interference to the primary user. 135 Regualtions to this effect have been specified by the FCC in the US 136 and other regulatory bodies in many other countries are also studying 137 similar approaches for parts of the spectrum. 139 One of the approaches to determining if spectrum is available at a 140 given location and time is to query a centralized database and obtain 141 information about what channels or spectrum can be used. There may 142 exist multiple databases from which such information can be obtained. 143 A standardized query/response mechanism is in the scope of the PAWS 144 working group. This document proposes a data format for the query 145 and response aspects of the protocol. 147 4. Problem Statement 149 The query/response protocol to obtain information about available 150 channels or spectrum can be specified using various means. LDAP is 151 an example of a protocol that can be used for this purpose. However 152 one of the objectives of this protocol is to ensure that it is 153 globally applicable and can be adapted for use in various regulatory 154 environments. The elements of the query and response can vary 155 depending on the country or region where a device is making a query 156 to a database. As a result of this objective, flexibility of the 157 protocol in terms of the attributes and parameters carried in the 158 query and response are quite important. 160 5. Protocol approach 162 This document does not specify the complete protocol itself. The 163 protocol can be split into three parts: 165 1. The data model 166 2. The transport protocol 167 3. The security solution 169 A data model for the query/response protocol is proposed in this 170 document. A hierarchical object model approach is used for defining 171 the query/response and its attributes. The figure below is a high- 172 level view of how the data model is structured: 174 ------------- 175 |WS Protocol| 176 ------------- 177 | 178 | 179 ------------------------------------- 180 | | 181 --------- ------------ 182 |wsQuery| |wsResponse| 183 --------- ------------ 184 | | 185 ---------- ---------- 186 |Element1| ...5, 6, 7 |Elementx| ... y,z 187 ---------- . . . ---------- . . 188 | . . . | . . 189 ------------ . . . ------------ . . 190 |Attributes| o o o o o |Attributes| o o o 191 ------------ ------------ 193 Figure 1: Data Model 195 6. Data Model details 197 The data model includes two main objects, the wsQuery and wsResponse 198 objects. Each of these objects contain a list of elements. The 199 elements are further comprised of attributes. The wsQuery object is 200 sent by a WS Master device to a database and the database responds 201 with a wsResponse object. The actual message and header in which 202 this object is carried is not specified here and is expected to be 203 specified elsewhere. Neither does this document specify how the 204 device discovers the database or how the object is transported or 205 secured. 207 6.1. White Space Query Object 209 The whitespaceQuery object is a data object carried in a request 210 message that any white space client (e.g. a white space device, 211 software application, coexistence manager, etc.) may use to request 212 information from a white space database, as part of a Rules-compliant 213 data transaction. 215 6.1.1. Query object definition 216 217 218 219 220 221 222 223 224 225 227 whitespaceQuery Object 229 6.2. White Space Response Object 231 A whitespaceResponse object is a generalized message response 232 structure that any white space administrator (e.g. a white space 233 database implementation) may use to communicate white space 234 information in a Rules-compliant data transaction. 236 The whitespaceResponse object structure is intended to accommodate 237 various responses to information queries from different white space 238 client such as, for example, white space devices (for transmission), 239 management systems (not for transmission) and consumers (not for 240 transmission). 242 6.2.1. Response Object Definition 244 245 246 247 249 250 251 252 253 254 255 256 257 258 259 whitespaceResponse Object 261 6.3. Elements of the Query and Response objects 263 The whitespaceQuery and whitespaceResponse objects include multiple 264 elements. Some of the elements are common across the query and 265 response objects. The following sections define these elements. 267 6.3.1. Station element 269 A WSIF station object contains information about the inquiring 270 station including antenna, location, transmitter details, etc. 272 273 274 275 276 277 278 279 281 283 285 289 290 291 292 293 294 295 297 Station Element 299 6.3.2. Schedule element 301 Type: Schedule 303 A schedule object is used by white space devices to request temporary 304 spectrum access (i.e. less than 24 hours). The schedule element is 305 intended to enable the recording, persistence and distribution of 306 standardized iCalendar-compatible messages. The format of the 307 Schedule object is defined in [RFC5545]. 309 6.3.3. ChannelList element 311 Type: Channel 313 A list of channels (i.e. frequency ranges) that are occupied by the 314 transmitter(s) at this station. 316 6.3.4. ContactList element 318 Type: Contact 320 A list of contacts associated with this station. For example, a 321 facility or on-site technical manager, administrator, and operational 322 contacts may be identified. 324 6.3.5. Location element 326 This element describes the station's physical and geographic 327 location. 329 330 331 332 333 334 335 336 337 338 339 340 342 Location Element 344 6.3.6. Antenna element 346 A description of this station's (transmit or receive) antenna, 347 including the required antenna parameters like pointing and elevation 348 information plus the radiation pattern. 350 351 352 353 354 355 356 357 358 359 360 361 362 363 365 Antenna Element 367 6.3.7. StationRxList element 369 Type: Station 371 For wireless services that include multiple stations, and especially 372 for wireless services with multiple TXRX stations, each receiving 373 station may indicate its respective upstream transmitting stations by 374 adding that transmitting station to this receiving stationis 375 rxStationList element. Example uses of this element include 376 Television translator stations, MVPD receive sites, etc. 378 6.3.8. TransmitterList element 380 Type: Transmitter 382 A station may support multiple transmitters operating within the same 383 geographic area and on the same schedule. For example, several 384 wireless microphones may operate simultaneously within the geographic 385 contour defined within this stationis location element. If the 386 stationType attribute indicates this station is receive-only then 387 this element SHOULD be null. 389 6.3.9. Address element 391 Type: Address 393 This element specifies the civic location of the station. The 394 structure of this element is described in [RFC5139]. 396 6.3.10. Coordinate element 398 Type: Coordinate 400 this element specifies the geolocation of the station. The structure 401 of this element is described in [RFC5491]. 403 6.3.11. RadiationPattern element 405 Type: RadiationPattern 407 A radiation pattern representing the directional (azimuth) dependence 408 of the strength of the radio signal from the antenna. The 409 radiationPattern represents the directional (azimuth) dependence of 410 the strength of the radio signal from the antenna. 412 A WKT MULTIPOINT SFA Geometry implementation. The azimuthal field 413 values are encoded as a well known text (WKT) MULTIPOINT object with 414 [azimuth, radial value] pairs encoded according to the format 415 POINT(x,y) = POINT(azimuth, field_value). 417 418 419 420 421 422 423 424 426 RadiationPattern Element 428 6.3.12. Contact Element 430 The contact represents a generalized container for individual 431 (person) and company (organization) contact information. The 432 structure of this element is defined in [RFC2426]. 434 6.3.13. Extension element 436 Type: xs:string 438 A URL-ENCODED string containing key/value pairs that requesting 439 devices may implement and administrators may support at their 440 discretion to provide supplementary information or to otherwise 441 extend this object. 443 6.3.14. WhiteSpaceFrequencyList element 445 Contains a complete and canonical list of available and valid white 446 space frequencies that is appropriate for the inquiring message's 447 criterion. For white space devices, the whitespaceFrequencyList 448 element represents all channels available for unlicensed operation at 449 the inquiring deviceis location or indicated geographic area and 450 according to the schedule in this element.Contains one or more 451 occurencies of WhiteSpaceFrequency elements. 453 6.3.15. WhiteSpaceFrequency element 455 456 457 458 459 460 461 462 463 464 466 WhiteSpaceFrequency Element 468 6.3.16. Channel Element 470 A channel describes a fully qualified and canonical frequency range. 471 Channel object definitions support positive definitions of colloquial 472 channel identifiers (e.g. TV channel 24) through identification of 473 the authorizing regulatory definition and the TV channelis frequency 474 range. 476 477 478 479 480 481 483 Channel Element 485 6.3.17. Transmitter Element 487 The transmitter object provides an extensible software template to 488 contain and exchange required and optional but otherwise useful 489 transmitter information. 491 A transmitter provides an object template for common device-related 492 attributes and may be optionally used directly or, more likely, may 493 be extended by other, more specific transmitter descriptions that 494 fully describe a certain type wireless device. For this reason all 495 transmitter attributes and elements are defined as optional by 496 default. Attribute and element validity is expected to be defined in 497 transmitter-derived objects. The transmitter is designed to support, 498 through extension, the communication of required and optional but 499 otherwise useful information about licensed and unlicensed wireless 500 devices including transmitters, receivers and transceivers. 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 526 Transmitter Element 528 6.4. Attributes definition 530 This section defines the attributes which are included in the various 531 elements of the whitespacequery or whitespaceresponse objects. 533 Channel attribute 534 Type: xs: boolean 535 Description: An indicator for whether the radiationPattern element 536 of this object contains interpolated values. 538 Source attribute 539 Type: xs:string 540 Description: The originating source of the data represented in the 541 radiationPattern element. An example value for this attribute is 542 ius.fcc.cdbsi. 544 Directional attribute 545 Type: xs:boolean 546 Descrition: Indicates whether the antenna is directional (true) or 547 non-directional (false). 549 Rotation attribute 550 Type: xs:float 551 Description: Indicates the offset in degrees azimuth [0, 360] from 552 true North that the antenna radiation pattern should be rotated. 554 HeightAboveGround attribute 555 Type: xs:float 556 Description: The antenna radiation center height above ground 557 level. 559 Manufacturer attribute 560 Type: xs:string 561 Description: The antenna manufacturer 563 x-elevantModel attribute 564 Type: xs:string 565 Description: The digital elevation model used to calculate this 566 antenna objectis HAAT (x-haat) and rcAMSL (x-rcAmsl) values. 568 x-govtAntennaId attribute 569 Type: xs:int 570 Description: A reference to the antenna ID record within FCC CDBS 572 x-haat attribute 573 Type: xs:float 574 Description: The antenna height above average terrain 576 x-rcAmsl attribute 577 Type: xs:float 578 Description: The antenna radiation center above mean sea level 580 Frequency attribute 581 Type: xs:double 582 Description: If a specific frequency has been assigned to this 583 transmitter that information may be recorded here in MHz. If only 584 the channel is provided then the assignedFrequency value is set to 585 the center frequency of this transmitteris channel. 587 deviceID attribute 588 Type: xs:string 589 Description: The transmitter device's Government provided 590 identifier. 592 deviceSn attribute 593 Type: xs:string 594 Description: the transmitting device's manufacturer-provided 595 serial number. 597 ea attribute 598 Type: xs:string 599 Description: The Government equipment authorization agency from 600 which this device is authorized to operate and which issued the 601 device ID. 603 erp attribute 604 Type: xs: float 605 Description: The transmitting deviceis current effective radiated 606 power (ERP), measured in dBw. 608 isDigital attribute 609 Type: xs:boolean 610 Description: Indicates whether this transmitter is sending a 611 digital (TRUE) or analog (FALSE) carrier. 613 manufacturer attribute 614 Type: xs:string 615 Description: the device manufacturer company name 617 Model attribute 618 Type: xs:string 619 Description: the antenna product model 621 allocation attribute 622 Type: xs:string 623 Description:A dot-delimited reverse domain encoded description of 624 the frequency allocation defined according the following strategy: 625 [country].[regulator].[allocation].[band range] 626 For example, the UHF-high block allocation of TV channels 38 to 51 627 within the United States is identified as "us.fcc.broadcast.614- 628 698". 630 channel attribute 632 Type: xs:float 633 Description: The colloquial channel number 634 Note: A FLOAT number type is used to accommodate future sub- 635 channelization. For the avoidance of doubt channel numbers ending 636 in zero shall be interpreted to represent a whole channel. i.e. 637 float value channel 38.0 is equivalent to integer-value channel 638 38. 640 effectiveDate attribute 642 Type: xs:dateTime 643 Description: The date and time when this white space information 644 should be considered effective. The value may be set in the 645 future to accommodate frequencies that may become available at a 646 later date or time. 648 expirationDate attribute 650 Type: xs:dateTime 651 Description: The date and time when this white space information 652 expires. 654 locationType attribute 656 Type: xs:string 657 Description: A descriptor string used to classify and organize 658 locations. If the location is derived from another database 659 source, this attribute is a dot-delimited string used to identify 660 this location type and its source. An example value for this 661 attribute is "us.fcc.cdbs.stationClass.CDT". 663 maxEIRP attribute 665 Type: xs:float 666 Description: The maximum allowable equivalent isotripically 667 radiated power (EIRP) that a white space device may transmit on 668 the indicated channel. Provided in dBW. 670 maxFreq attribute 672 Type: xs:double 673 Description: The maximum (or end) frequency of the indicated 674 channel in MHz. 676 messageType attribute 678 Type: xs:string 679 Description: An enumerated message type. Allowed message types 680 are: 681 Message code: ws.messageType.TVBD.QUERY 682 Description: The message is a certified client-initiated query for 683 white space frequency information for the purposes of 684 transmission. Examples of certified clients include FCC-certified 685 white space devices and other devices authorized to operate within 686 the band (e.g. wireless microphones, medical telemetry, PLMRS 687 systems, etc.) 688 Message code: ws.messageType.TVBD.RESPONSE 689 Description: The message is a response to a TVBD.QUERY request for 690 information. 691 Message code: ws.messageType.INFORMATION.QUERY 692 Description: The message is a non-certified client-initiated query 693 for general (possibly white-space) frequency information NOT for 694 the purposes of transmission. Examples of non-certified clients 695 include network management and planning systems, client software 696 applications, etc. 697 Message code: ws.messageType.INFORMATION.RESPONSE 698 Description: The message is a response to an INFORMATION.QUERY 699 request for information. 701 minFreq attribute 703 Type: xs:double 704 Description: The minimum (or start) frequency of the indicated 705 channel in MHz. 707 name attribute 708 Type: xs:string 709 Description: A human readable name or label that may be used to 710 identify a location or station. A useful hint is to use a 711 memorable place name as might be represented on a map (e.g. 712 "Empire State Building"). For licensed wireless services it is 713 recommended to use the facility call sign. For unlicensed 714 wireless services it is recommended to use the venue name. 716 protocolVersion attribute 718 Type: xs:float 719 Description: The message protocol version. 721 stationClass attribute 723 Type: xs:string 724 Description: Indicates the station classification. Classification 725 may be used to determine whether and how many elements of this 726 station are required for validation. Allowed values are: 727 TX. This is a transmitting station and a transmitter is required 728 in the transmitterList element 729 RX. This is a receive-only station and a transmitter element is 730 NOT required 731 TXRX. This station is able to both transmit and receive and a 732 transmitter is required in the transmitterList element. 734 stationType attribute 736 Type: xs:string 737 Description: A description of this station's operation. 739 statusIndicator attribute 741 Type: xs:int 742 Description: The number of available white space channels included 743 in the message. A negative value indicates that an error 744 condition has occured. 746 timeStamp attribute 748 Type: xs:dateTime 749 Description: When the message was created. 751 uuid attribute 753 Type: xs:string 754 Description (for use in Location):A universally unique identifier 755 (UUID) associated with and permanently assigned to this location. 756 Description (for use in Station):A universally unique identifier 757 (UUID) associated with and permanently assigned to this station. 758 Description (for use in whitespaceFrequency): A universally unique 759 idenfifier (UUID) assigned by an Administrator that is associated 760 with this freuquency 761 Description (for use in whitespaceQuery): A universally unique 762 identifier (UUID) created by the inquiring agent (i.e. a TV band 763 device, user software, etc.) and associated with this whitespace 764 query message. This uuid may be used to correlate a 765 whitespaceResponse message with this whitespaceQuery and to 766 simplify logging and archival. 767 Description (for use in whitespaceResponse): A universally unique 768 identifier (UUID), set to match the client's whitespaceQuery.uuid 769 attribute and to simplify logging and arhival. 771 x-geocode attribute 773 Type: xs:string 774 Description: An enumerated value indicating whether any one of 775 this location object's components have been calculated according 776 to another of this location object's set parameters. 777 Allowed values are: 778 NO (xs:string) (DEFAULT). The coordinate, address and geometry 779 elements of this location are not correlated. 780 GC (xs:string). The coordinate.[longitude, latitude] and 781 geometry.point values have been calculated and set according to a 782 Geo-coding algorithm from the address. 783 RG (xs:string). The address has been calculated and set according 784 to a Reverse Geo-coding algorithm from the coordinate.[longitude, 785 latitude] value. 787 x-haat attribute 789 Type: xs:float 790 Description: The ground height above average terrain value at this 791 location's coordinates, calculated according to the methodology 792 described in 47 CFR 73.684(d). The elevation model used in the 793 calculation of this location attribute is recorded in the 794 coordinate.x-elevationModel attribute. This value is used to 795 support TVBD transmit antenna compliance with 15.709(b)(2), which 796 states that the ground level HAAT must be below 76 meters. 798 x-timeZone attribute 799 Type: xs:string 800 Description: The local time zone at this location. Two 801 interchangeable formats are supported, with the zoneinfo format 802 preferred: 803 The zoneinfo database format (e.g. "America/New_York") 804 An offset to Coordinated Universal Time (e.g. "UTC-05:00" or 805 "UTC-5" 806 Note: Three-character notation (e.g. "EDT") is not supported. 808 7. IANA Considerations 810 This document will require actions on the part of IANA to assign 811 values for the new messages and attributes. 813 8. Security Considerations 815 This document defines the data model for the database query and 816 response protocol to be used between white space devices and a 817 database. The actual security for the messages that transport these 818 objects needs to be specified in the relevant document. 820 9. Acknowledgements 822 This document has been made possible as a result of the efforts of 823 Basavaraj Patil and Scott Probasco. 825 10. References 827 10.1. Normative References 829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", BCP 14, RFC 2119, March 1997. 832 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 833 RFC 2426, September 1998. 835 [RFC5139] Thomson, M. and J. Winterbottom, "Revised Civic Location 836 Format for Presence Information Data Format Location 837 Object (PIDF-LO)", RFC 5139, February 2008. 839 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 840 Presence Information Data Format Location Object (PIDF-LO) 841 Usage Clarification, Considerations, and Recommendations", 842 RFC 5491, March 2009. 844 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 845 Core Object Specification (iCalendar)", RFC 5545, 846 September 2009. 848 10.2. Informative References 850 [I-D.ietf-paws-problem-stmt-usecases-rqmts] 851 Probasco, S., Bajko, G., Patil, B., and B. Rosen, 852 "Protocol to Access White Space database: PS, use cases 853 and rqmts", draft-ietf-paws-problem-stmt-usecases-rqmts-00 854 (work in progress), September 2011. 856 Author's Address 858 Jesse Caufield 859 Key Bridge 860 1600 Tysons Blvd, Suite 450 861 McLean VA 22102 862 USA 864 Email: jesse.caulfield@keybridgeglobal.com