draft-ietf-paws-protocol-15.txt   draft-ietf-paws-protocol-16.txt 
PAWS V. Chen, Ed. PAWS V. Chen, Ed.
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track S. Das Intended status: Standards Track S. Das
Expires: February 27, 2015 Applied Communication Sciences Expires: March 9, 2015 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
iconectiv iconectiv
P. McCann P. McCann
Huawei Huawei
August 26, 2014 September 5, 2014
Protocol to Access White-Space (PAWS) Databases Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-15 draft-ietf-paws-protocol-16
Abstract Abstract
Portions of the radio spectrum that are allocated to licensees are Portions of the radio spectrum that are allocated to licensees are
available for non-interfering use. This available spectrum is called available for non-interfering use. This available spectrum is called
"White Space." Allowing secondary users access to available spectrum "White Space." Allowing secondary users access to available spectrum
"unlocks" existing spectrum to maximize its utilization and to "unlocks" existing spectrum to maximize its utilization and to
provide opportunities for innovation, resulting in greater overall provide opportunities for innovation, resulting in greater overall
spectrum utilization. spectrum utilization.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 27, 2015. This Internet-Draft will expire on March 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 33 skipping to change at page 3, line 33
6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 55 6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 55
6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 56 6.3. Example Encoding: spectrum.paws.getSpectrum Method . . . 56
6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 60 6.4. Example Encoding: DeviceOwner vCard . . . . . . . . . . . 60
7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 60 7. HTTPS Binding . . . . . . . . . . . . . . . . . . . . . . . . 60
8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 62 8. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 62 8.1. Defining Ruleset Identifiers . . . . . . . . . . . . . . 62
8.2. Defining New Message Parameters . . . . . . . . . . . . . 63 8.2. Defining New Message Parameters . . . . . . . . . . . . . 63
8.3. Defining Additional Error Codes . . . . . . . . . . . . . 63 8.3. Defining Additional Error Codes . . . . . . . . . . . . . 63
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63
9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 64 9.1. PAWS Ruleset ID Registry . . . . . . . . . . . . . . . . 64
9.1.1. Registration Template . . . . . . . . . . . . . . . . 65 9.1.1. Registration Template . . . . . . . . . . . . . . . . 64
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 66 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 66
9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 73 9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 72
9.2.1. Registration Template . . . . . . . . . . . . . . . . 73 9.2.1. Registration Template . . . . . . . . . . . . . . . . 72
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 73 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 72
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 75 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 74
9.3.1. Registration Template . . . . . . . . . . . . . . . . 76 9.3.1. Registration Template . . . . . . . . . . . . . . . . 75
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 76 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 76 10. Security Considerations . . . . . . . . . . . . . . . . . . . 75
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 78 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 77
10.2. Protection Against Modification . . . . . . . . . . . . 78 10.2. Protection Against Modification . . . . . . . . . . . . 77
10.3. Protection Against Eavesdropping . . . . . . . . . . . . 78 10.3. Protection Against Eavesdropping . . . . . . . . . . . . 77
10.4. Client Authentication Considerations . . . . . . . . . . 79 10.4. Client Authentication Considerations . . . . . . . . . . 78
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 79 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.1. Normative References . . . . . . . . . . . . . . . . . . 80 13.1. Normative References . . . . . . . . . . . . . . . . . . 79
13.2. Informative References . . . . . . . . . . . . . . . . . 81 13.2. Informative References . . . . . . . . . . . . . . . . . 80
Appendix A. Database Listing Server Support . . . . . . . . . . 82 Appendix A. Database Listing Server Support . . . . . . . . . . 81
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 83 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction 1. Introduction
[RFC Editor: In the Author's Addresses section, please list [RFC Editor: In the Author's Addresses section, please list
"iconectiv" as "iconectiv (formerly Telcordia Interconnection "iconectiv" as "iconectiv (formerly Telcordia Interconnection
Solutions). One occurrence."] Solutions). One occurrence."]
This section provides some high level introductory material. Readers This section provides some high level introductory material. Readers
are strongly encouraged to read "Protocol to Access White-Space are strongly encouraged to read "Protocol to Access White-Space
(PAWS) Databases: Use Cases and Requirements" [RFC6953] for use (PAWS) Databases: Use Cases and Requirements" [RFC6953] for use
skipping to change at page 11, line 7 skipping to change at page 11, line 7
Error Handling Error Handling
The device SHOULD select another database from its list of The device SHOULD select another database from its list of
preconfigured databases if: preconfigured databases if:
o The selected database is unreachable or does not respond. o The selected database is unreachable or does not respond.
o The selected database returns an UNSUPPORTED error (see Error o The selected database returns an UNSUPPORTED error (see Error
Codes (Section 5.17)), which indicates the database does not Codes (Section 5.17)), which indicates the database does not
support the device (based on its device type, model, etc.) or does support the device (based on its device type, model, etc.) or
not support any rulesets specified in the request. supports none of the rulesets specified in the request.
If a suitable database cannot be contacted, the device MUST treat If a suitable database cannot be contacted, the device MUST treat
this as equivalent to a response indicating no available spectrum. this as equivalent to a response indicating no available spectrum.
If the device had previously contacted a database to get available If the device had previously contacted a database to get available
spectrum, but subsequently fails to contact a suitable database, the spectrum, but subsequently fails to contact a suitable database, the
spectrum the device is currently using can be used for as long as the spectrum the device is currently using can be used for as long as the
spectrum data is valid; but after that period, the device will no spectrum data is valid; but after that period, the device will no
longer have valid spectrum to use. Some regulatory domains may have longer have valid spectrum to use. Some regulatory domains may have
specific rules regarding how long the spectrum data remains valid in specific rules regarding how long the spectrum data remains valid in
these cases. these cases.
skipping to change at page 12, line 52 skipping to change at page 12, line 52
Parameters: Parameters:
deviceDesc: The DeviceDescriptor (Section 5.2) for the device is deviceDesc: The DeviceDescriptor (Section 5.2) for the device is
REQUIRED. If the device descriptor does not contain any ruleset REQUIRED. If the device descriptor does not contain any ruleset
IDs, the Master Device is asking the Database to return a IDs, the Master Device is asking the Database to return a
RulesetInfo (Section 5.6) list that specifies the rulesets that it RulesetInfo (Section 5.6) list that specifies the rulesets that it
supports at the specified location. supports at the specified location.
location: The GeoLocation (Section 5.1) of the device is REQUIRED. location: The GeoLocation (Section 5.1) of the device is REQUIRED.
If the location is outside any regulatory domain supported by the If the location is outside all regulatory domain supported by the
Database, the Database MUST respond with an OUTSIDE_COVERAGE Database, the Database MUST respond with an OUTSIDE_COVERAGE
(Table 1) error. (Table 1) error.
other: The Master Device MAY specify additional handshake parameters other: The Master Device MAY specify additional handshake parameters
in the INIT_REQ message. The Database MUST ignore all parameters in the INIT_REQ message. The Database MUST ignore all parameters
it does not understand. To simplify its initialization logic, a it does not understand. To simplify its initialization logic, a
Master Device that supports multiple Databases and rulesets can Master Device that supports multiple Databases and rulesets can
include the union of all required parameters for all its supported include the union of all required parameters for all its supported
rulesets. Consult the PAWS Parameters Registry (Section 9.2) for rulesets. Consult the PAWS Parameters Registry (Section 9.2) for
possible additional parameters. possible additional parameters.
skipping to change at page 13, line 46 skipping to change at page 13, line 46
INIT_REQ (Section 4.3.1) message. INIT_REQ (Section 4.3.1) message.
If the device included a list of ruleset IDs in the If the device included a list of ruleset IDs in the
DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the DeviceDescriptor of its INIT_REQ message, each RulesetInfo in the
response MUST match one of the specified ruleset IDs. response MUST match one of the specified ruleset IDs.
If the DeviceDescriptor did not contain any ruleset IDs, the If the DeviceDescriptor did not contain any ruleset IDs, the
Database SHOULD include in the rulesetInfos list a RulesetInfo for Database SHOULD include in the rulesetInfos list a RulesetInfo for
each ruleset it supports at the specified location. each ruleset it supports at the specified location.
If the Database does not support the device or any of the rulesets If the Database does not support the device or supports none of
specified in the DeviceDescriptor, it MUST instead return an error the rulesets specified in the DeviceDescriptor, it MUST instead
with the UNSUPPORTED (Table 1) code in the error response. return an error with the UNSUPPORTED (Table 1) code in the error
response.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the Master Device of a change to the (Section 5.7) to notify the Master Device of a change to the
Database URI, providing one or more alternate database URIs. The Database URI, providing one or more alternate database URIs. The
device needs to update its preconfigured entry for the responding device needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. database with the alternate databases listed in the DbUpdateSpec.
other: The Database MAY include additional handshake parameters in other: The Database MAY include additional handshake parameters in
the INIT_RESP (Section 4.3.2) message. The Master Device MUST the INIT_RESP (Section 4.3.2) message. The Master Device MUST
ignore all parameters it does not understand. Consult the PAWS ignore all parameters it does not understand. Consult the PAWS
skipping to change at page 15, line 52 skipping to change at page 15, line 52
registration parameters. To simplify its registration logic, the registration parameters. To simplify its registration logic, the
Master Device MAY send a union of the registration information Master Device MAY send a union of the registration information
required by all supported rulesets. The Database MUST ignore all required by all supported rulesets. The Database MUST ignore all
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
Registry (Section 9.2) for possible additional parameters. Registry (Section 9.2) for possible additional parameters.
4.4.2. REGISTRATION_RESP 4.4.2. REGISTRATION_RESP
The registration response message acknowledges successful The registration response message acknowledges successful
registration by including a RulesetInfo message for each ruleset in registration by including a RulesetInfo message for each ruleset in
which the registration is accepted. If the Database does not accept which the registration is accepted. If the Database accepts none the
the registration for any of the rulesets it supports, the Database registration for its supported rulesets, the Database MUST return the
MUST return the NOT_REGISTERED error (See Error Codes NOT_REGISTERED error (See Error Codes (Section 5.17)).
(Section 5.17)).
+---------------------------------------+ +---------------------------------------+
|REGISTRATION_RESP | |REGISTRATION_RESP |
+----------------------------+----------+ 1..* +-------------+ +----------------------------+----------+ 1..* +-------------+
|rulesetInfos:list | required |------->| RulesetInfo | |rulesetInfos:list | required |------->| RulesetInfo |
|databaseChange:DbUpdateSpec | optional | +-------------+ |databaseChange:DbUpdateSpec | optional | +-------------+
|............................|..........| |............................|..........|
|*other:any | optional | |*other:any | optional |
+----------------------------+----------+ +----------------------------+----------+
Parameters: Parameters:
rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in rulesetInfos: A RulesetInfo (Section 5.6) list MUST be included in
the response. Each entry corresponds to a ruleset for which the the response. Each entry corresponds to a ruleset for which the
registration was accepted. The list MUST contain at least one registration was accepted. The list MUST contain at least one
entry. entry.
Each RulesetInfo in the response MUST match one of the ruleset IDs Each RulesetInfo in the response MUST match one of the ruleset IDs
specified in the DeviceDescriptor of REGISTRATION_REQ. specified in the DeviceDescriptor of REGISTRATION_REQ.
If the Database does not support the device or any of the rulesets If the Database does not support the device or supports none of
specified in the DeviceDescriptor, it MUST instead return an error the rulesets specified in the DeviceDescriptor, it MUST instead
with the UNSUPPORTED (Table 1) code in the error response. return an error with the UNSUPPORTED (Table 1) code in the error
response.
databaseChange: The Database MAY include a DbUpdateSpec databaseChange: The Database MAY include a DbUpdateSpec
(Section 5.7) to notify the Master Device of a change to the (Section 5.7) to notify the Master Device of a change to the
Database URI, providing one or more alternate database URIs. The Database URI, providing one or more alternate database URIs. The
device needs to update its preconfigured entry for the responding device needs to update its preconfigured entry for the responding
database with the alternate databases listed in the DbUpdateSpec. database with the alternate databases listed in the DbUpdateSpec.
other: Database implementations MAY return additional parameters in other: Database implementations MAY return additional parameters in
the registration response. The Master Device MUST ignore any the registration response. The Master Device MUST ignore any
parameters it does not understand. Consult the PAWS Parameters parameters it does not understand. Consult the PAWS Parameters
skipping to change at page 18, line 10 skipping to change at page 18, line 10
2. The Database MUST respond with an error using the NOT_REGISTERED 2. The Database MUST respond with an error using the NOT_REGISTERED
(Table 1) code if: (Table 1) code if:
* registration information is required, and * registration information is required, and
* the request does not include registration information, and * the request does not include registration information, and
* the device has not previously registered with the Database * the device has not previously registered with the Database
3. If the location specified in the request is outside the 3. If the location specified in the request is outside the
regulatory domain supported by the Database, the Database MUST regulatory domain supported by the Database, the Database MUST
respond with an OUTSIDE_COVERAGE (Table 1) error. If some respond with an OUTSIDE_COVERAGE (Table 1) error. If some, but
locations within a batch request are outside the regulatory not all, locations within a batch request are outside the
domain supported by the Database, the Database MAY return an OK regulatory domain supported by the Database, the Database MUST
response with available spectrum for only the valid locations; return an OK response with available spectrum for only the valid
otherwise, if all locations within a batch request are outside locations; otherwise, if all locations within a batch request are
the regulatory domain, the Database MUST respond with an outside the regulatory domain, the Database MUST respond with an
OUTSIDE_COVERAGE error. OUTSIDE_COVERAGE error.
4. The Database MAY perform other validation of the request, (e.g., 4. The Database MAY perform other validation of the request, (e.g.,
checking for missing required parameters, authorizations). If checking for missing required parameters, authorizations). If
validation fails, the Database returns an appropriate error code validation fails, the Database returns an appropriate error code
(Table 1). If the request is missing required parameters, the (Table 1). If the request is missing required parameters, the
Database MUST respond with a MISSING (Table 1) error and SHOULD Database MUST respond with a MISSING (Table 1) error and SHOULD
include a list of the missing parameters. include a list of the missing parameters.
5. If the request is valid, the Database responds with an available- 5. If the request is valid, the Database responds with an available-
skipping to change at page 21, line 45 skipping to change at page 21, line 45
The response message for the Available Spectrum Query contains one or The response message for the Available Spectrum Query contains one or
more SpectrumSpec (Section 5.9) elements, one for each ruleset more SpectrumSpec (Section 5.9) elements, one for each ruleset
supported at the location specified in the corresponding supported at the location specified in the corresponding
AVAIL_SPECTRUM_REQ (Section 4.5.1) request. Each SpectrumSpec AVAIL_SPECTRUM_REQ (Section 4.5.1) request. Each SpectrumSpec
element contains a list of one or more spectrum schedules, element contains a list of one or more spectrum schedules,
representing permissible power levels over time: representing permissible power levels over time:
o Each spectrum schedule specifies permissible power level for a o Each spectrum schedule specifies permissible power level for a
duration defined by a pair of start and stop times. The power duration defined by a pair of start and stop times. The power
levels typically refer to permissible EIRP over a resolution levels refer to permissible EIRP over a resolution bandwidth.
bandwidth.
o Within each list of schedules, event-time intervals MUST be o Within each list of schedules, event-time intervals MUST be
disjoint and MUST be sorted in increasing time. disjoint and MUST be sorted in increasing time.
o A gap in the time schedule means no spectrum is available for that o A gap in the time schedule means no spectrum is available for that
time interval. time interval.
Consider a Database that provides a schedule of available spectrum Consider a Database that provides a schedule of available spectrum
for the next 24 hours. If spectrum availability were to be different for the next 24 hours. If spectrum availability were to be different
at different times of day, the response would contain a list of at different times of day, the response would contain a list of
skipping to change at page 28, line 19 skipping to change at page 28, line 19
Device, the location is that of the Slave Device and is OPTIONAL, Device, the location is that of the Slave Device and is OPTIONAL,
but may be required by some rulesets. but may be required by some rulesets.
spectra: The Spectrum (Section 5.11) list is REQUIRED, and specifies spectra: The Spectrum (Section 5.11) list is REQUIRED, and specifies
the spectrum anticipated to be used by the device, which includes the spectrum anticipated to be used by the device, which includes
profiles of frequencies and power levels. The list MAY be empty, profiles of frequencies and power levels. The list MAY be empty,
if the device decides not to use any spectrum. For consistency, if the device decides not to use any spectrum. For consistency,
the resolution bandwidth value, "resolutionBwHz" MUST match that the resolution bandwidth value, "resolutionBwHz" MUST match that
from one of the Spectrum (Section 5.11) elements in the from one of the Spectrum (Section 5.11) elements in the
corresponding AVAIL_SPECTRUM_RESP message, and the maximum power corresponding AVAIL_SPECTRUM_RESP message, and the maximum power
levels in the Spectrum element MUST be expressed as power over the levels in the Spectrum element MUST be expressed as power (EIRP)
specified "resolutionBwHz" value. The actual bandwidth to be used over the specified "resolutionBwHz" value. The actual bandwidth
(as computed from the start and stop frequencies) MAY be different to be used (as computed from the start and stop frequencies) MAY
from the "resolutionBwHz" value. As an example, when the ruleset be different from the "resolutionBwHz" value. As an example, when
expresses maximum power spectral density in terms of maximum power the ruleset expresses maximum power spectral density in terms of
over any 100 kHz band, then the "resolutionBwHz" value should be maximum power over any 100 kHz band, then the "resolutionBwHz"
set to 100 kHz, even though the actual bandwidth used can be 20 value should be set to 100 kHz, even though the actual bandwidth
kHz. used can be 20 kHz.
masterDeviceDesc: When the notification is made by the Master Device masterDeviceDesc: When the notification is made by the Master Device
on behalf of a Slave Device, the Master Device MAY provide its own on behalf of a Slave Device, the Master Device MAY provide its own
descriptor. descriptor.
masterDeviceLocation: When the notification is made by the Master masterDeviceLocation: When the notification is made by the Master
Device on behalf of a Slave Device, the Master Device MUST include Device on behalf of a Slave Device, the Master Device MUST include
its own GeoLocation (Section 5.1). its own GeoLocation (Section 5.1).
other: Depending on the ruleset, other parameters may be required. other: Depending on the ruleset, other parameters may be required.
skipping to change at page 34, line 50 skipping to change at page 34, line 50
manufacturer, and therefore ought to be consistent across all manufacturer, and therefore ought to be consistent across all
devices from the same manufacturer and distinct from that of other devices from the same manufacturer and distinct from that of other
manufacturers. Its maximum length is 64 octets. manufacturers. Its maximum length is 64 octets.
modelId: The device's model ID is OPTIONAL, but may be required by modelId: The device's model ID is OPTIONAL, but may be required by
some rulesets. Its maximum length is 64 octets. some rulesets. Its maximum length is 64 octets.
rulesetIds: The list of identifiers for rulesets supported by the rulesetIds: The list of identifiers for rulesets supported by the
device (see Ruleset ID Registry (Section 9.1)). A Database MAY device (see Ruleset ID Registry (Section 9.1)). A Database MAY
require that the device provides this list before servicing the require that the device provides this list before servicing the
device requests. If the Database does not support any of the device requests. If the Database supports none of the rulesets
rulesets specified in the list, the Database MAY refuse to service specified in the list, the Database MAY refuse to service the
the device requests. See RulesetInfo (Section 5.6) for discussion device requests. See RulesetInfo (Section 5.6) for discussion on
on ruleset identifier. If present, the list MUST contain at least ruleset identifier. If present, the list MUST contain at least
one entry. one entry.
other: Depending on the ruleset, other parameters may be required. other: Depending on the ruleset, other parameters may be required.
The Database MUST ignore all parameters in the message it does not The Database MUST ignore all parameters in the message it does not
understand. See PAWS Parameters Registry (Section 9.2) for understand. See PAWS Parameters Registry (Section 9.2) for
additional valid parameters and for the process for extending the additional valid parameters and for the process for extending the
message with more parameters. Additionally, see PAWS Ruleset ID message with more parameters. Additionally, see PAWS Ruleset ID
Registry (Section 9.1) for the valid set of parameters for each Registry (Section 9.1) for the valid set of parameters for each
ruleset. ruleset.
skipping to change at page 50, line 4 skipping to change at page 50, line 4
PAWS Error Code Registry (Section 9.3). PAWS Error Code Registry (Section 9.3).
Code Name Description & Additional parameters Code Name Description & Additional parameters
------ ---------------- --------------------------------------------- ------ ---------------- ---------------------------------------------
0 (reserved) 0 (reserved)
-100 (reserved) -100 (reserved)
-101 VERSION The Database does not support the specified -101 VERSION The Database does not support the specified
version of the message. This error does not version of the message. This error does not
use any additional data. use any additional data.
-102 UNSUPPORTED The Database does not support the device. For -102 UNSUPPORTED The Database does not support the device. For
example, it does not support any ruleset example, it supports none of the ruleset
specified in the request or does not support specified in the request or does not support
the device, based on its device type, model, the device, based on its device type, model,
etc. This error does not use any additional etc. This error does not use any additional
data. data.
-103 UNIMPLEMENTED The Database does not implement the optional -103 UNIMPLEMENTED The Database does not implement the optional
request or optional feature. This error does request or optional feature. This error does
not use any additional data. not use any additional data.
-104 OUTSIDE_COVERAGE The specified geolocation is outside the -104 OUTSIDE_COVERAGE The specified geolocation is outside the
coverage area of the Database. The Database coverage area of the Database. The Database
MAY include a DbUpdateSpec (Section 5.7) to MAY include a DbUpdateSpec (Section 5.7) to
skipping to change at page 61, line 7 skipping to change at page 61, line 7
7. HTTPS Binding 7. HTTPS Binding
This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS) This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS)
as the transfer mechanism for PAWS. TLS provides message integrity as the transfer mechanism for PAWS. TLS provides message integrity
and confidentiality between the Master Device and the Database, but and confidentiality between the Master Device and the Database, but
only when best current practices are adopted, including use of only when best current practices are adopted, including use of
recommended cipher suites and modes of operation. Consequently, to recommended cipher suites and modes of operation. Consequently, to
improve PAWS security and interoperability, implementations of the improve PAWS security and interoperability, implementations of the
Database and Master Device MUST follow best current practices defined Database and Master Device MUST follow best current practices defined
by Recommendations for Secure Use of TLS and DTLS by Recommendations for Secure Use of TLS and DTLS
[I-D.ietf-uta-tls-bcp]. Additionally, to improve performance, the [I-D.ietf-uta-tls-bcp].
Master Device SHOULD use Online Certificate Status Protocol - OCSP
[RFC6960] to check the validity of the Database certificate, rather
than downloading Certificate Revocation Lists (CRLs).
Depending on prior relationship between a database and device, the Depending on prior relationship between a database and device, the
server MAY require client authentication, as described in the server MAY require client authentication, as described in the
"Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate "Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate
the device. When client authentication is required, the database the device. When client authentication is required, the database
MUST specify, by prior arrangement, acceptable root Certificate MUST specify, by prior arrangement, acceptable root Certificate
Authorities (CAs) to serve as trust anchors for device certificates. Authorities (CAs) to serve as trust anchors for device certificates.
To enable databases to handle large numbers of requests from large To enable databases to handle large numbers of requests from large
numbers of devices, the Database MAY support and devices SHOULD numbers of devices, the Database MAY support and devices SHOULD
skipping to change at page 81, line 20 skipping to change at page 80, line 20
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
August 2011. August 2011.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, June 2013.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
January 2014. January 2014.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
13.2. Informative References 13.2. Informative References
skipping to change at page 83, line 46 skipping to change at page 82, line 46
uris One or more URIs for each database, allowing a database to uris One or more URIs for each database, allowing a database to
support more than one protocol. support more than one protocol.
uri, protocol Each protocol supported by a certified database is uri, protocol Each protocol supported by a certified database is
associated with a separate URI (PAWS protocol URI shown). associated with a separate URI (PAWS protocol URI shown).
Appendix B. Changes / Author Notes. Appendix B. Changes / Author Notes.
[RFC Editor: Remove this section before publication.] [RFC Editor: Remove this section before publication.]
Changes from 15:
o More precise language: "supports none of the ruleset" instead of
"does not support any ruleset", where it makes sense.
o Batch request: Change MAY to MUST when some locations are
acceptable
o Remove explicit mention of OCSP and leave it up the the TLS best
practices draft
o Define power levels are EIRP for consistency
Changes from 14: Changes from 14:
o Clarified why spectrum-notify is "informational" o Clarified why spectrum-notify is "informational"
o Clarified that device registration is typically only required for o Clarified that device registration is typically only required for
fixed devices fixed devices
o Global statement about timestamp format and must be UTC o Global statement about timestamp format and must be UTC
o Global statement about MISSING error returned, whether it's o Global statement about MISSING error returned, whether it's
 End of changes. 19 change blocks. 
67 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/