draft-ietf-paws-protocol-13.txt   draft-ietf-paws-protocol-14.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: January 31, 2015 Applied Communication Sciences Expires: February 1, 2015 Applied Communication Sciences
L. Zhu L. Zhu
Huawei Huawei
J. Malyar J. Malyar
iconectiv (formerly Telcordia Interconnection Solutions) iconectiv
P. McCann P. McCann
Huawei Huawei
July 30, 2014 July 31, 2014
Protocol to Access White-Space (PAWS) Databases Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-13 draft-ietf-paws-protocol-14
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 January 31, 2015. This Internet-Draft will expire on February 1, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions Used in This Document . . . . . . . . . . . . 4 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7 3.1. Multi-ruleset Support . . . . . . . . . . . . . . . . . . 7
4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 8 4. Protocol Functionalities . . . . . . . . . . . . . . . . . . 8
4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 9 4.1. Database Discovery . . . . . . . . . . . . . . . . . . . 9
4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 10 4.2. PAWS Version . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 11 4.3. Initialization . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. INIT_REQ . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. INIT_RESP . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Device Registration . . . . . . . . . . . . . . . . . . . 13 4.4. Device Registration . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 3, line 23 skipping to change at page 3, line 23
5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 47 5.15. GeoSpectrumSpec . . . . . . . . . . . . . . . . . . . . . 47
5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 48 5.16. DeviceValidity . . . . . . . . . . . . . . . . . . . . . 48
5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 49 5.17. Error Element . . . . . . . . . . . . . . . . . . . . . . 49
5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 51 5.17.1. OUTSIDE_COVERAGE Error . . . . . . . . . . . . . . . 51
5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . 51 5.17.2. DATABASE_CHANGE Error . . . . . . . . . . . . . . . 51
5.17.3. MISSING Error . . . . . . . . . . . . . . . . . . . 51 5.17.3. MISSING Error . . . . . . . . . . . . . . . . . . . 51
6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 52 6. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 52
6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 52 6.1. JSON-RPC Binding . . . . . . . . . . . . . . . . . . . . 52
6.1.1. Method Names . . . . . . . . . . . . . . . . . . . . 54 6.1.1. Method Names . . . . . . . . . . . . . . . . . . . . 54
6.1.2. JSON Encoding of Data Models . . . . . . . . . . . . 54 6.1.2. JSON Encoding of Data Models . . . . . . . . . . . . 54
6.2. Example Encoding: init Method . . . . . . . . . . . . . . 55 6.2. Example Encoding: spectrum.paws.init Method . . . . . . . 55
6.3. Example Encoding: 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 . . . . . . . . . . . . . 62 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 . . . . . . . . . . . . . . . . 64 9.1.1. Registration Template . . . . . . . . . . . . . . . . 64
9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 65 9.1.2. Initial Registry Contents . . . . . . . . . . . . . . 66
9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 71 9.2. PAWS Parameters Registry . . . . . . . . . . . . . . . . 72
9.2.1. Registration Template . . . . . . . . . . . . . . . . 71 9.2.1. Registration Template . . . . . . . . . . . . . . . . 72
9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 71 9.2.2. Initial Registry Contents . . . . . . . . . . . . . . 72
9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 73 9.3. PAWS Error Code Registry . . . . . . . . . . . . . . . . 74
9.3.1. Registration Template . . . . . . . . . . . . . . . . 74 9.3.1. Registration Template . . . . . . . . . . . . . . . . 75
9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 74 9.3.2. Initial Registry Contents . . . . . . . . . . . . . . 75
10. Security Considerations . . . . . . . . . . . . . . . . . . . 74 10. Security Considerations . . . . . . . . . . . . . . . . . . . 75
10.1. Assurance of Proper Database . . . . . . . . . . . . . . 76 10.1. Assurance of Proper Database . . . . . . . . . . . . . . 77
10.2. Protection Against Modification . . . . . . . . . . . . 76 10.2. Protection Against Modification . . . . . . . . . . . . 77
10.3. Protection Against Eavesdropping . . . . . . . . . . . . 76 10.3. Protection Against Eavesdropping . . . . . . . . . . . . 77
10.4. Client Authentication Considerations . . . . . . . . . . 76 10.4. Client Authentication Considerations . . . . . . . . . . 77
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 77 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.1. Normative References . . . . . . . . . . . . . . . . . . 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 79
13.2. Informative References . . . . . . . . . . . . . . . . . 79 13.2. Informative References . . . . . . . . . . . . . . . . . 80
Appendix A. Database Listing Server Support . . . . . . . . . . 80 Appendix A. Database Listing Server Support . . . . . . . . . . 81
Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 81 Appendix B. Changes / Author Notes. . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
1. Introduction 1. Introduction
[RFC Editor: In the Author's Addresses section, please list
"iconectiv" as "iconectiv (formerly Telcordia Interconnection
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
cases, requirements, and additional background. cases, requirements, and additional background.
A geospatial database can track available spectrum (in accordance A geospatial database can track available spectrum (in accordance
with the rules of one or more regulatory domains) and make this with the rules of one or more regulatory domains) and make this
information available to devices. This approach shifts the information available to devices. This approach shifts the
complexity of spectrum-policy conformance out of the device and into complexity of spectrum-policy conformance out of the device and into
the database. This approach also simplifies adoption of policy the database. This approach also simplifies adoption of policy
skipping to change at page 5, line 12 skipping to change at page 5, line 18
document are to be interpreted as described in "Key words for use in document are to be interpreted as described in "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119]. RFCs to Indicate Requirement Levels" [RFC2119].
2.2. Terminology 2.2. Terminology
Database or Spectrum Database: A database is an entity that contains Database or Spectrum Database: A database is an entity that contains
current information about available spectrum at a given location current information about available spectrum at a given location
and time, as well as other types of information related to and time, as well as other types of information related to
spectrum availability and usage. spectrum availability and usage.
Device ID An identifier for a device. Device ID: An identifier for a device.
ETSI: European Telecommunications Standards Institute ETSI: European Telecommunications Standards Institute
(http://www.etsi.org)
FCC: Federal Communications Commission FCC: The U.S. Federal Communications Commission
(http://www.fcc.gov)
Listing server: A server that provides the URIs for one or more Listing server: A server that provides the URIs for one or more
Spectrum Databases. A regulator, for example, may operate a Spectrum Databases. A regulator, for example, may operate a
Database Listing Server to publish the list of authorized Spectrum Database Listing Server to publish the list of authorized Spectrum
Databases for its regulatory domain. Databases for its regulatory domain.
Master Device: A device that queries the database, on its own behalf Master Device: A device that queries the database, on its own behalf
and/or on behalf of a slave device, to obtain available spectrum and/or on behalf of a slave device, to obtain available spectrum
information. information.
skipping to change at page 9, line 5 skipping to change at page 9, line 13
optional device authentication. optional device authentication.
The parameter tables in this section and Protocol Parameters The parameter tables in this section and Protocol Parameters
(Section 5) are for reference and contain the name of each parameter, (Section 5) are for reference and contain the name of each parameter,
the data type of each parameter, and whether the existence of the the data type of each parameter, and whether the existence of the
parameter is required for the protocol transaction in question. The parameter is required for the protocol transaction in question. The
diagrams are loosely based on UML, and the data types are defined diagrams are loosely based on UML, and the data types are defined
either in Protocol Parameters (Section 5) or are one of the following either in Protocol Parameters (Section 5) or are one of the following
primitive or structured types: primitive or structured types:
string A string, as defined by JSON [RFC7159], restricted to the string: A string, as defined by JSON [RFC7159], restricted to the
UTF-8 encoding. UTF-8 encoding.
int A number, as defined by JSON [RFC7159], without a fractional or int: A number, as defined by JSON [RFC7159], without a fractional or
exponent part. exponent part.
float A number, as defined by JSON [RFC7159]. float: A number, as defined by JSON [RFC7159].
boolean A boolean, as defined by JSON [RFC7159]. boolean: A boolean, as defined by JSON [RFC7159].
list A structured type that represents a list of elements, as list: A structured type that represents a list of elements, as
defined by JSON [RFC7159] array type. All elements of the list defined by JSON [RFC7159] array type. All elements of the list
are of the same data type, which is indicated in its diagram and are of the same data type, which is indicated in its diagram and
description. The diagram notation and description may include description. The diagram notation and description may include
additional constraints, such as minimum or maximum number of additional constraints, such as minimum or maximum number of
elements. elements.
NOTE: All parameter names are case sensitive. Unless stated NOTE: All parameter names are case sensitive. Unless stated
otherwise, all string values are case sensitive. otherwise, all string values are case sensitive.
4.1. Database Discovery 4.1. Database Discovery
skipping to change at page 54, line 39 skipping to change at page 54, line 39
Table 2 Table 2
6.1.2. JSON Encoding of Data Models 6.1.2. JSON Encoding of Data Models
JSON [RFC7159] encoding of the data models described in Section 4 and JSON [RFC7159] encoding of the data models described in Section 4 and
Section 5 is straightforward: Section 5 is straightforward:
o Each data model describes the contents of a JSON object o Each data model describes the contents of a JSON object
o Each parameter of a data model corresponds to a member of the o Each parameter of a data model corresponds to a member of the
corresponding JSON object corresponding JSON object:
* The parameter name of the data model is the same as the member * The parameter name of the data model is the same as the member
name of the JSON object name of the JSON object
* The parameter data type describes the type of the member value * The parameter data type describes the type of the member value
o Primitive types map to JSON type, as described in Section 4, o Primitive types map to JSON type, as described in Section 4,
repeated here: repeated here:
string A JSON string, restricted to UTF-8 encoding string: A JSON string, restricted to UTF-8 encoding
int A JSON number, without a fractional or exponent part int: A JSON number, without a fractional or exponent part
float A JSON number float: A JSON number
boolean One of the JSON values, true or false boolean: One of the JSON values, true or false
o The list type maps to a JSON array, except that all values in the o The list type maps to a JSON array, except that all values in the
array are of the same type array are of the same type
o When the parameter data type refers to another data model, that o When the parameter data type refers to another data model, that
data model describes a nested JSON object data model describes a nested JSON object
o The encoded JSON object for each of the Request and Response o The encoded JSON object for each of the Request and Response
message listed in the Method Names Table (Table 2) also includes message listed in the Method Names Table (Table 2) also includes
the following members: the following members:
type The name of the message, e.g., "INIT_REQ" type: The name of the message, e.g., "INIT_REQ"
version The PAWS version, e.g., "1.0" version: The PAWS version, e.g., "1.0"
See the following sections for examples. See the following sections for examples.
6.2. Example Encoding: init Method 6.2. Example Encoding: spectrum.paws.init Method
An example of the "init" JSON-RPC request is shown below; An example of the "spectrum.paws.init" JSON-RPC request is shown
below;
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "spectrum.paws.init", "method": "spectrum.paws.init",
"params": { "params": {
"type": "INIT_REQ", "type": "INIT_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
skipping to change at page 56, line 22 skipping to change at page 56, line 22
"authority": "us", "authority": "us",
"rulesetId": "FccTvBandWhiteSpace-2010", "rulesetId": "FccTvBandWhiteSpace-2010",
"maxLocationChange": 100, "maxLocationChange": 100,
"maxPollingSecs": 86400 "maxPollingSecs": 86400
} }
] ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
6.3. Example Encoding: getSpectrum Method 6.3. Example Encoding: spectrum.paws.getSpectrum Method
An example of the "getSpectrum" JSON-RPC request is shown below: An example of the "spectrum.paws.getSpectrum" JSON-RPC request is
shown below:
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"method": "spectrum.paws.getSpectrum", "method": "spectrum.paws.getSpectrum",
"params": { "params": {
"type": "AVAIL_SPECTRUM_REQ", "type": "AVAIL_SPECTRUM_REQ",
"version": "1.0", "version": "1.0",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
"fccId": "YYY", "fccId": "YYY",
skipping to change at page 56, line 47 skipping to change at page 56, line 48
"location": { "location": {
"point": { "point": {
"center": {"latitude": 37.0, "longitude": -101.3} "center": {"latitude": 37.0, "longitude": -101.3}
} }
}, },
"antenna": {"height": 10.2, "heightType": "AGL"} "antenna": {"height": 10.2, "heightType": "AGL"}
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
The following example "getSpectrum" JSON-RPC response contains: The following example "spectrum.paws.getSpectrum" JSON-RPC response
contains:
o A schedule with two time ranges o A schedule with two time ranges
o A spectrum profile for one resolution bandwidth (6 MHz) o A spectrum profile for one resolution bandwidth (6 MHz)
o The power levels for two frequency segments are shown: o The power levels for two frequency segments are shown:
* From 518 MHz to 542 MHz * From 518 MHz to 542 MHz
* From 620 MHz to 626 MHz * From 620 MHz to 626 MHz
o In practice, each "profiles" list contains (frequency, power) o In practice, each "profiles" list contains (frequency, power)
points to cover all frequencies governed by the associated points to cover all frequencies governed by the associated
ruleset. See the Spectrum (Section 5.11) section for a more ruleset. See the Spectrum (Section 5.11) section for a more
detailed discussion on the representation. detailed discussion on the representation.
skipping to change at page 58, line 27 skipping to change at page 58, line 30
... ...
] ]
} }
] ]
} }
] ]
}, },
"id": "xxxxxx" "id": "xxxxxx"
} }
The following example "getSpectrum" JSON-RPC response includes a The following example "spectrum.paws.getSpectrum" JSON-RPC response
spectrum profile that contains specifications for two different includes a spectrum profile that contains specifications for two
bandwidth resolutions (6 MHz and 100 kHz): different bandwidth resolutions (6 MHz and 100 kHz):
{ {
"jsonrpc": "2.0", "jsonrpc": "2.0",
"result": { "result": {
"type": "AVAIL_SPECTRUM_RESP", "type": "AVAIL_SPECTRUM_RESP",
"version": "1.0", "version": "1.0",
"timestamp": "2013-03-02T14:30:21Z", "timestamp": "2013-03-02T14:30:21Z",
"deviceDesc": { "deviceDesc": {
"serialNumber": "XXX", "serialNumber": "XXX",
... ...
skipping to change at page 63, line 46 skipping to change at page 64, line 4
number of this document as indicated below, and remove this note number of this document as indicated below, and remove this note
prior to publication] prior to publication]
There are three registries associated with PAWS: There are three registries associated with PAWS:
o PAWS Ruleset ID Registry (Section 9.1) o PAWS Ruleset ID Registry (Section 9.1)
o PAWS Parameter Registry (Section 9.2) o PAWS Parameter Registry (Section 9.2)
o PAWS Error Code Registry (Section 9.3) o PAWS Error Code Registry (Section 9.3)
Prior to registration, the registrant is encouraged to post to the
A registrant should contact IANA directly at http://www.iana.org to paws@ietf.org mailing list, including the specification or its draft,
apply for new registry assignments. Prior to the registration to get early feedback.
request, the registrant is encouraged to post to the paws@ietf.org
mailing list, including the specification or its draft, to get early
feedback.
All registries use the Specification Required policy [RFC5226], with All registries use the Specification Required policy [RFC5226], with
a Designated Expert appointed by the IESG. Specific criteria that a Designated Expert appointed by the IESG. Specific criteria that
the Designated Expert should use in assessing registrations are given the Designated Expert should use in assessing registrations are given
below in the description of each registry. The Designated Expert below in the description of each registry. The Designated Expert
should take advice from the community through the paws@ietf.org should take advice from the community through the paws@ietf.org
mailing list, and the registrant is encouraged to post to the mailing mailing list, and the registrant is encouraged to post to the mailing
list before formally requesting the registration from IANA. The list before formally requesting the registration from IANA. The
intention is that new registrations will be accompanied by a intention is that new registrations will be accompanied by a
published specification. But in order to allow for the allocation of published specification. But in order to allow for the allocation of
values prior to publication of the specification, the Designated values prior to publication of the specification, the Designated
Expert can approve allocations once it seems clear that the Expert can approve allocations once it seems clear that the
specification will be published. specification will be published. Upon approval, IANA will post each
registration template that is not included in the text of an RFC.
9.1. PAWS Ruleset ID Registry 9.1. PAWS Ruleset ID Registry
This specification establishes the PAWS Ruleset ID Registry. This specification establishes the PAWS Ruleset ID Registry.
Ruleset type names for inclusion in PAWS messages are registered on Ruleset type names for inclusion in PAWS messages are registered on
the advice of one or more Designated Experts, with Specification the advice of one or more Designated Experts, with Specification
Required [RFC5226]. The specification must include a reference to Required [RFC5226]. The specification must include a reference to
the regulatory domain to which it applies. To increase the regulatory domain to which it applies. To increase
interoperability, it is more desirable to have fewer rulesets than to interoperability, it is more desirable to have fewer rulesets than to
have many rulesets with small variations. Consequently, the have many rulesets with small variations. Consequently, the
Designated Expert should avoid duplication and should encourage the Designated Expert should avoid duplication and should encourage the
registrant to look for alternatives if there are only small registrant to look for alternatives if there are only small
variations from an existing ruleset. The Designated Expert should variations from an existing ruleset. The Designated Expert should
ensure that the proposed registration is complete with respect to its ensure that the proposed registration is complete with respect to its
associated regulatory domain and may seek an expert familiar with associated regulatory domain and may seek an expert familiar with
those rules to participate in the review on the paws@ietf.org mailing those rules to participate in the review on the paws@ietf.org mailing
list. list.
The PAWS Ruleset ID Registry will include the following: 'Ruleset
identifier', 'Specification document(s)', and 'Additional Parameter
Requirements'.
9.1.1. Registration Template 9.1.1. Registration Template
Ruleset identifier: The name of the ruleset. See [[ this document Ruleset identifier: The name of the ruleset. See [[ this document
]], Section 8.1 for the format requirements of this identifier. ]], Section 8.1 for the format requirements of this identifier.
Specification document(s): Reference to the document that specifies Specification document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included, but is not required.
Additional parameter requirements: List of additional parameters to Additional Parameter Requirements: Listing of additional parameter
associate with the ruleset ID and any additional requirements on requirements to associate with the ruleset. Note that new
message parameters. New parameters are registered separately in parameters are registered separately in the PAWS Parameters
the PAWS Parameters Registry, as described by Section 8.2. Registry, as described by Section 8.2. Two types of additional
parameter requirements are:
* Addition of new parameters to existing structures, or
modification of the REQUIRED and OPTIONAL requirements for
existing parameters.
* Modification of requirements to existing parameter values.
For adding new parameters or modifying requirements of existing
parameters, the registration should include a table for each
affected structure that lists the structure's parameter changes.
Each table should include a structure name in its heading and have
the following columns:
Parameter name: Name of the parameter added or modified.
Type: Data type of the parameter value.
Requirement: Whether the parameter is REQUIRED or OPTIONAL for
the ruleset.
Notes: Any additional notes that might be useful to implementors.
For modifying requirements to existing parameter values, the
registration should include a table for each affected structure
that lists the structure's parameter changes. Each table should
include a structure name in its heading and have the following
columns:
Parameter name: Name of the parameter.
Type: Data type of the parameter value.
Additional requirements: Additional requirements on the parameter
value.
IANA will post each registration template that is not included in the
text of an RFC.
9.1.2. Initial Registry Contents 9.1.2. Initial Registry Contents
The PAWS Ruleset ID Registry enables protocol extensibility to The PAWS Ruleset ID Registry enables protocol extensibility to
support any regulatory domain and ruleset. The initial contents of support any regulatory domain and ruleset. The initial contents of
the registry, however, include only FCC-specific and ETSI-specific the registry, however, include only FCC-specific and ETSI-specific
entries, because, as of this writing, they are the only regulatory entries, because, as of this writing, they are the only regulatory
domains that have finalized rules. There is no intent to restrict domains that have finalized rules. There is no intent to restrict
the protocol to any particular set of authorities. the protocol to any particular set of authorities.
The initial contents of the PAWS Ruleset ID Registry are listed The initial contents of the PAWS Ruleset ID Registry are listed
below; each section corresponds to a single row in the registry. The below; each section corresponds to a single entry in the registry.
PAWS Ruleset ID Registry will include the following parameters:
'Ruleset name', 'Additional parameter requirements', and
'Specification document(s)'. IANA will post each registration
template that is not included in the text of an RFC.
9.1.2.1. Federal Communications Commission (FCC) 9.1.2.1. Federal Communications Commission (FCC)
For the additional parameters that start with the "fcc" prefix, see For the additional parameters that start with the "fcc" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.2.2) for more PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
information. information.
Ruleset identifier: FccTvBandWhiteSpace-2010 Ruleset identifier: FccTvBandWhiteSpace-2010
Specification document(s): This ruleset refers to the FCC rules for Specification document(s): This ruleset refers to the FCC rules for
TV-band White Space operations established in the Code of Federal TV-band White Space operations established in the Code of Federal
Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H]. Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H].
Additional Parameter Requirements
Each of the following tables defines additional parameters for the Each of the following tables defines additional parameters for the
indicated PAWS message. Note that the Requirement column lists FCC, indicated PAWS message. Note that the Requirement column lists FCC,
not PAWS, requirements/optionality rules, not PAWS, requirements/optionality rules,
Available Spectrum Request (Section 4.5.1) Available Spectrum Request (Section 4.5.1)
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
| Parameter | Type | Requirement | Notes | | Parameter | Type | Requirement | Notes |
| Name | | | | | Name | | | |
+---------------+-----------------------------+-------------+-------+ +---------------+-----------------------------+-------------+-------+
skipping to change at page 66, line 30 skipping to change at page 67, line 30
| | | | FCC certification ID | | | | | FCC certification ID |
| | | | (Section 9.2.2.1). | | | | | (Section 9.2.2.1). |
| fccTvbdDeviceType | string | REQUIRED | Specifies the FCC | | fccTvbdDeviceType | string | REQUIRED | Specifies the FCC |
| | | | Device Type (Section | | | | | Device Type (Section |
| | | | 9.2.2.2) of TV-band | | | | | 9.2.2.2) of TV-band |
| | | | White Space device, as | | | | | White Space device, as |
| | | | defined by the FCC | | | | | defined by the FCC |
| | | | rules. | | | | | rules. |
+-------------------+--------+-------------+------------------------+ +-------------------+--------+-------------+------------------------+
The following table lists additional DeviceOwner (Section 5.5) The following table lists additional requirements for DeviceOwner
parameter requirements. (Section 5.5) parameter values.
DeviceOwner (Section 5.5) DeviceOwner (Section 5.5)
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| Parameter | Type | Additional Requirement | | Parameter | Type | Additional Requirement |
| Name | | | | Name | | |
+-----------+-------+-----------------------------------------------+ +-----------+-------+-----------------------------------------------+
| owner | vCard | The owner is required to contain the | | owner | vCard | The owner is required to contain the |
| | | formatted name of an individual or | | | | formatted name of an individual or |
| | | organization using the "fn" property. When | | | | organization using the "fn" property. When |
skipping to change at page 67, line 16 skipping to change at page 68, line 16
For the additional parameters that start with the "etsi" prefix, see For the additional parameters that start with the "etsi" prefix, see
PAWS Parameters Registry Initial Contents (Section 9.2.2) for more PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
information. information.
Ruleset identifier: ETSI-EN-301-598-1.1.1 Ruleset identifier: ETSI-EN-301-598-1.1.1
Specification document(s): This ruleset refers to the ETSI Specification document(s): This ruleset refers to the ETSI
Harmonised Standard [ETSI-EN-301-598] established by ETSI. Harmonised Standard [ETSI-EN-301-598] established by ETSI.
Additional Parameter Requirements
Each of the following tables defines additional parameters for the Each of the following tables defines additional parameters for the
indicated PAWS message. Note that the Requirement column lists ETSI, indicated PAWS message. Note that the Requirement column lists ETSI,
not PAWS, requirements/optionality rules, not PAWS, requirements/optionality rules,
DeviceDescriptor (Section 5.2) DeviceDescriptor (Section 5.2)
+-------------------------+-------+-------------+-------------------+ +-------------------------+-------+-------------+-------------------+
| Parameter Name | Type | Requirement | Notes | | Parameter Name | Type | Requirement | Notes |
+-------------------------+-------+-------------+-------------------+ +-------------------------+-------+-------------+-------------------+
| manufacturerId | strin | REQUIRED | Specifies a | | manufacturerId | strin | REQUIRED | Specifies a |
| | g | | device's | | | g | | device's |
skipping to change at page 71, line 24 skipping to change at page 72, line 24
new parameter when an existing one suffices. When a set of new parameter when an existing one suffices. When a set of
parameters is added in support of a new ruleset (Section 9.1), the parameters is added in support of a new ruleset (Section 9.1), the
parameters should share a common prefix that reflects the ruleset ID. parameters should share a common prefix that reflects the ruleset ID.
The prefix may be omitted, of course, if a parameter has more general The prefix may be omitted, of course, if a parameter has more general
applicability. Similarly, when a parameter is not associated with a applicability. Similarly, when a parameter is not associated with a
ruleset, the Designated Expert should ensure that the parameter name ruleset, the Designated Expert should ensure that the parameter name
does not have a prefix used by existing ruleset parameters (e.g., does not have a prefix used by existing ruleset parameters (e.g.,
"fcc", "etsi") or are the initials of an organization that has not "fcc", "etsi") or are the initials of an organization that has not
yet registered anything, but reasonably might. yet registered anything, but reasonably might.
The PAWS Parameters Registry will include the following: 'Parameter
name', 'Parameter usage location', and 'Specification document(s)'.
9.2.1. Registration Template 9.2.1. Registration Template
Parameter name: The name of the parameter (e.g., "example"). Parameter name: The name of the parameter (e.g., "example").
Parameter usage location: The location(s) where the parameter can be Parameter usage location: The location(s) where the parameter can be
used. The possible locations are the named requests, responses, used. The possible locations are the named structures defined in
and messages defined in Protocol Functionalities (Section 4) and Protocol Functionalities (Section 4) and Protocol Parameters
Protocol Parameters (Section 5). (Section 5).
Specification document(s): Reference to the document that specifies Specification document(s): Reference to the document that specifies
the parameter, preferably including a URI that can be used to the parameter, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant retrieve a copy of the document. An indication of the relevant
sections also may be included, but is not required. sections also may be included, but is not required.
9.2.2. Initial Registry Contents 9.2.2. Initial Registry Contents
The PAWS Parameters Registry enables protocol extensibility to The PAWS Parameters Registry enables protocol extensibility to
support any regulatory domain and ruleset. The initial contents of support any regulatory domain and ruleset. The initial contents of
the registry, however, include only FCC-specific and ETSI-specific the registry, however, include only FCC-specific and ETSI-specific
entries, because, as of this writing, they are the only regulatory entries, because, as of this writing, they are the only regulatory
domains that have established rules. There is no intent to restrict domains that have established rules. There is no intent to restrict
the protocol to any particular set of authorities. the protocol to any particular set of authorities.
The PAWS Parameters Registry's initial contents are listed below; The PAWS Parameters Registry's initial contents are listed below;
each section corresponds to a row of the registry. The PAWS each section corresponds to a row of the registry.
Parameters Registry will include the following parameters: 'Parameter
name', 'Parameter usage location', and 'Specification document(s)'.
IANA will post each registration template that is not included in the
text of an RFC.
9.2.2.1. FCC ID 9.2.2.1. FCC ID
Parameter name: fccId Parameter name: fccId
Parameter usage location: DeviceDescriptor (Section 5.2) Parameter usage location: DeviceDescriptor (Section 5.2)
Specification document(s): [[ this document ]] Specifies the Specification document(s): [[ this document ]] Specifies the
device's FCC certification identifier. A valid FCC ID is limited device's FCC certification identifier. A valid FCC ID is limited
to 19 characters in the ASCII value range, as proposed in FCC to 19 characters in the ASCII value range, as proposed in FCC
skipping to change at page 74, line 7 skipping to change at page 75, line 7
registered on the advice of one or more Designated Experts, with registered on the advice of one or more Designated Experts, with
Specification Required [RFC5226]. Specification Required [RFC5226].
Error codes are intended to be used for automated error handling by Error codes are intended to be used for automated error handling by
devices. Before approval, the Designated Expert should consider devices. Before approval, the Designated Expert should consider
whether a device would handle the new error code differently from an whether a device would handle the new error code differently from an
existing error code, or whether the difference could be communicated existing error code, or whether the difference could be communicated
effectively to the end-user via the "reason" parameter of the Error effectively to the end-user via the "reason" parameter of the Error
(Section 5.17) object. (Section 5.17) object.
The PAWS Error Code Registry will include the following: 'Code',
'Name', 'Description and Additional parameters'.
9.3.1. Registration Template 9.3.1. Registration Template
Code: Integer value of the error code. The value MUST be an Code: Integer value of the error code. The value MUST be an
unassigned value in the range -32768 to 32767, inclusive. unassigned value in the range -32768 to 32767, inclusive.
Name: Name of the error. Name: Name of the error.
Description: Description of the error and its associated parameters, Description and Additional parameters: Description of the error and
if any. its associated parameters, if any. It also lists additional
parameters that are returned in the data portion of the error (See
Additional parameters: Additional parameters that are returned in Section 5.17). New parameters MUST be registered separately in
the data portion of the error (See Section 5.17). New parameters the PAWS Parameters Registry, as described by Section 9.2.
MUST be registered separately in the PAWS Parameters Registry, as
described by Section 9.2.
9.3.2. Initial Registry Contents 9.3.2. Initial Registry Contents
Initial registry contents are defined in the Table of Error Codes Initial registry contents are defined in the Table of Error Codes
(Table 1). Note that the third column, "Description & Additional (Table 1).
parameters", contains both the description of the error code and the
specification of additional parameters, when applicable.
The PAWS Error Code Registry will include the following parameters: The registry will also include the error-code categories describing
'Code', 'Name', 'Description', and 'Additional parameters'. The
registry will also include the error-code categories describing
-100s, -200s, and -300s as a note (see Error Codes (Section 5.17)). -100s, -200s, and -300s as a note (see Error Codes (Section 5.17)).
IANA will post each registration template that is not included in the
text of an RFC.
10. Security Considerations 10. Security Considerations
PAWS is a protocol whereby a Master Device requests a schedule of PAWS is a protocol whereby a Master Device requests a schedule of
available spectrum at its location (or location of its Slave Devices) available spectrum at its location (or location of its Slave Devices)
before it (they) can operate using those frequencies. Whereas the before it (they) can operate using those frequencies. Whereas the
information provided by the Database must be accurate and conform to information provided by the Database must be accurate and conform to
the applicable ruleset, the Database cannot enforce, through the the applicable ruleset, the Database cannot enforce, through the
protocol, that a client device uses only the spectrum it provided. protocol, that a client device uses only the spectrum it provided.
In other words, devices can put energy in the air and cause In other words, devices can put energy in the air and cause
skipping to change at page 81, line 18 skipping to change at page 82, line 18
name The name of the database operator. name The name of the database operator.
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.
To be removed before publication [RFC Editor: Remove this section before publication.]
Changes from 13:
o Clarification in IANA Section 9
o Use full method name in description of the JSON examples in
Section 6
o Ask RFC Editor to give full iconectiv name in the Addresses
section
o Add URI to ETSC and FCC
Changes from 12: Changes from 12:
o Define primitive types in Section 4, specifying UTF-8 for strings o Define primitive types in Section 4, specifying UTF-8 for strings
and remove UTF-8 references elsewhere. and remove UTF-8 references elsewhere.
o Replace or rephrase "parameter" when reference is to higher-level o Replace or rephrase "parameter" when reference is to higher-level
structure. structure.
o Replace "MUST" with non-2119 language (maximum length is xxx o Replace "MUST" with non-2119 language (maximum length is xxx
skipping to change at page 87, line 33 skipping to change at page 89, line 4
Basking Ridge, NJ 07920 Basking Ridge, NJ 07920
U.S.A. U.S.A.
Email: sdas at appcomsci dot com Email: sdas at appcomsci dot com
Lei Zhu Lei Zhu
Huawei Huawei
Phone: +86 13910157020 Phone: +86 13910157020
Email: lei.zhu@huawei.com Email: lei.zhu@huawei.com
John Malyar John Malyar
iconectiv (formerly Telcordia Interconnection Solutions) iconectiv
444 Hoes Lane/RRC 4E1106 444 Hoes Lane/RRC 4E1106
Piscataway, NJ 08854 Piscataway, NJ 08854
U.S.A. U.S.A.
Email: jmalyar at iconectiv dot com Email: jmalyar at iconectiv dot com
Peter J. McCann Peter J. McCann
Huawei Huawei
400 Crossing Blvd, 2nd Floor 400 Crossing Blvd, 2nd Floor
Bridgewater, NJ 08807 Bridgewater, NJ 08807
USA USA
Phone: +1 908 541 3563 Phone: +1 908 541 3563
Email: peter.mccann@huawei.com Email: peter.mccann@huawei.com
 End of changes. 52 change blocks. 
96 lines changed or deleted 151 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/