tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7545

 
 
 

Protocol to Access White-Space (PAWS) Databases

Part 4 of 4, p. 66 to 90
Prev RFC Part

 


prevText      Top      Up      ToC       Page 66 
7.  HTTPS Binding

   This section describes the use of "HTTP Over TLS" [RFC2818] (HTTPS)
   as the transfer mechanism for PAWS.  TLS provides message integrity
   and confidentiality between the Master Device and the Database, but
   only when best current practices are adopted, including use of
   recommended cipher suites and modes of operation.  Consequently, to
   improve PAWS security and interoperability, implementations of the
   Database and Master Device MUST follow best current practices defined
   by "Recommendations for Secure Use of Transport Layer Security (TLS)
   and Datagram Transport Layer Security (DTLS)" [RFC7525].

   Depending on a prior relationship between a Database and device, the
   server MAY require client authentication, as described in the
   "Transport Layer Security (TLS) Protocol" [RFC5246], to authenticate

Top      Up      ToC       Page 67 
   the device.  When client authentication is required, the Database
   MUST specify, by prior arrangement, acceptable root Certification
   Authorities (CAs) to serve as trust anchors for device certificates.

   To enable Databases to handle large numbers of requests from large
   numbers of devices, the Database MAY support and devices SHOULD
   support "Stateless TLS Session Resumption" [RFC5077].

   A PAWS request message is carried in the body of an HTTP POST
   request.  A PAWS response message is carried in the body of an HTTP
   response.  A PAWS response SHOULD include a Content-Length header.

   The POST method is the only method REQUIRED for PAWS.  If a Database
   chooses to support GET, it MUST be an escaped URI, but the encoding
   of the URI is outside the scope of this document.  The Database MAY
   refuse to support the GET request by returning an HTTP error code,
   such as 405 (method not allowed).

   The Database MAY redirect a PAWS request by returning a HTTP 3xx
   response (as defined by Section 6.4 of "HTTP/1.1: Semantics and
   Content" [RFC7231]).  The Database MUST provide the redirect URI in
   the Location header of the 3xx response, and the device MUST handle
   redirects by using the Location header provided by the Database.
   When redirecting, the device MUST observe the delay indicated by the
   Retry-After header.  The device MUST authenticate the Database that
   returns the redirect response before following the redirect.  Also,
   the device MUST authenticate the Database indicated in the redirect.
   Since the device may communicate with a Database (which it
   authenticated) without user interaction, when the response code is
   301 (Moved Permanently), the device MAY redirect without asking a
   user for confirmation, even thought it is in response to an HTTP POST
   method.

   The Database SHOULD use HTTP status code "307 Temporary Redirect" to
   indicate that the device SHOULD resubmit the same request to an
   alternate URI.  The device MAY revert to the original URI for the
   very next request, or it MAY continue to use the alternate URI for a
   period of time, e.g.,:

   o  For the remainder of its session, or

   o  For a fixed period of time, or

   o  Until power cycled, or

   o  Until it receives another redirect

   However, the device does not need to modify its stored list of URIs.

Top      Up      ToC       Page 68 
   For a minimum of two weeks before the URI of the Database changes
   permanently, it MUST use the database-change (DbUpdateSpec
   (Section 5.7)) mechanism to notify devices, as described in
   "Configuration Update: Database URI Changes" (Section 4.1.2).  After
   the Database has moved, requests to the original URI MAY return HTTP
   status code 301 (Moved Permanently) to indicate that the device
   SHOULD resubmit the request, and all future requests, to the
   indicated alternate URI.

8.  Extensibility

   This section describes procedures for extending PAWS.  No extensions
   should be made that would return sensitive device-specific
   information in database responses.

8.1.  Defining Ruleset Identifiers

   A ruleset represents a set of device-side requirements for which the
   device has been certified.  It typically corresponds to, but is not
   limited to, a set of rules that govern a specific set of radio
   spectrum for a regulatory domain.

   Ruleset identifiers are defined and registered in the Ruleset ID
   Registry following the procedure in Section 9.1.  Ruleset ID values
   MUST conform to the ruleset-id ABNF.  If the Ruleset ID requires
   additional parameters, they are registered in the PAWS Parameters
   Registry, as described by Section 9.2.  The ABNF syntax [RFC5234] is
   as follows.

   ruleset-id   = 1*64ruleset-char
   ruleset-char = ALPHA / DIGIT / "_" / "."

   When defining a Ruleset ID:

   o  It can be useful for the identifier to be descriptive of the set
      of rules that allow a device to operate within one or more
      regulatory domains.  For example, it might include the name of a
      regulatory body or a certification process.

   o  The identifier SHOULD include some sort of version information,
      such as a year and/or version number.

   o  The maximum length of the identifier is 64 octets.

Top      Up      ToC       Page 69 
8.2.  Defining New Message Parameters

   New request or response parameters for use with PAWS are defined and
   registered in the parameters registry following the procedure in
   Section 9.2.

   Parameter names MUST conform to the param-name ABNF, and parameter
   values syntax MUST be well-defined (e.g., using ABNF or a reference
   to the syntax of an existing parameter).

   param-name = 1*64name-char
   name-char  = ALPHA / DIGIT / "_"

   Parameter names use lowerCamelCase by convention.  The maximum length
   of a name is 64 octets.

   Unregistered vendor-specific parameter extensions that are not
   commonly applicable and are specific to the implementation details of
   the Database where they are used SHOULD use a vendor-specific prefix
   that is not likely to conflict with other registered values (e.g.,
   begin with 'companyname').

8.3.  Defining Additional Error Codes

   Additional error codes can be registered to extend the set listed in
   Section 5.17, following the procedures in Section 9.3.  If the error
   code requires additional response parameters, they are registered in
   the PAWS Parameters Registry, as described by Section 9.2.

   By convention, the error code is a negative integer value, using one
   of the range of values defined in Error Codes (Section 5.17).  If an
   appropriate category does not exist, a value from a different range
   may be used.

9.  IANA Considerations

   There are three registries associated with PAWS:

   o  PAWS Ruleset ID Registry (Section 9.1)

   o  PAWS Parameter Registry (Section 9.2)

   o  PAWS Error Code Registry (Section 9.3)

   All registries use the Specification Required policy [RFC5226], with
   a Designated Expert appointed by the IESG.  Specific criteria that
   the Designated Expert should use in assessing registrations are given
   below in the description of each registry.  The Designated Expert

Top      Up      ToC       Page 70 
   should take advice from the community through the paws@ietf.org
   mailing list, and the registrant is encouraged to post to the mailing
   list before formally requesting the registration from IANA.  The
   intention is that new registrations will be accompanied by a
   published specification.  But in order to allow for the allocation of
   values prior to publication of the specification, the Designated
   Expert can approve allocations once it seems clear that the
   specification will be published.  Upon approval, IANA will post the
   registrations that are not intended to be published in an RFC.

9.1.  PAWS Ruleset ID Registry

   This specification establishes the "PAWS Ruleset ID Registry".

   Ruleset type names for inclusion in PAWS messages are registered on
   the advice of one or more Designated Experts, with Specification
   Required [RFC5226].  The specification must include a reference to
   the regulatory domain to which it applies.  To increase
   interoperability, it is more desirable to have fewer rulesets than to
   have many rulesets with small variations.  Consequently, the
   Designated Expert should avoid duplication and should encourage the
   registrant to look for alternatives if there are only small
   variations from an existing ruleset.  The Designated Expert should
   ensure that the proposed registration is complete with respect to its
   associated regulatory domain and may seek an expert familiar with
   those rules to participate in the review on the paws@ietf.org mailing
   list.

   The PAWS Ruleset ID Registry includes the following: 'Ruleset
   Identifier', 'Reference', and 'Template'.  The Template column will
   include links to the registration templates, either posted by IANA or
   linked to the relevant sections of RFCs.

9.1.1.  Registration Template

   Ruleset identifier:  The name of the ruleset.  See Section 8.1 of RFC
      7545 for the format requirements of this identifier.

   Specification document(s):  Reference to the document that specifies
      the parameter, preferably including a URI that can be used to
      retrieve a copy of the document.  An indication of the relevant
      sections also may be included but is not required.

Top      Up      ToC       Page 71 
   Additional Parameter Requirements:  Listing of additional parameter
      requirements to associate with the ruleset.  Note that new
      parameters are registered separately in the PAWS Parameters
      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 intended to be
   published in an RFC.

   Note that the Additional Parameter Requirements section can be quite
   extensive, so it will not appear directly in the IANA Ruleset ID
   Registry table.  The table, however, will contain a link to the full
   registration template for easy access to the additional requirements.

Top      Up      ToC       Page 72 
9.1.2.  Initial Registry Contents

   The PAWS Ruleset ID Registry enables protocol extensibility to
   support any regulatory domain and ruleset.  The initial contents of
   the registry, however, include only FCC-specific and ETSI-specific
   entries, because, as of this writing, they are the only regulatory
   domains that have finalized rules.  There is no intent to restrict
   the protocol to any particular set of authorities.

   The initial contents of the PAWS Ruleset ID Registry are listed
   below; each section corresponds to a single entry in the registry.

9.1.2.1.  Federal Communications Commission (FCC)

   For the additional parameters that start with the "fcc" prefix, see
   PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
   information.

   Ruleset identifier:  FccTvBandWhiteSpace-2010

   Specification document(s):  This ruleset refers to the FCC rules for
      TV-band white-space operations established in the Code of Federal
      Regulations (CFR), Title 47, Part 15, Subpart H [FCC-CFR47-15H].

   Additional Parameter Requirements

   Each of the following tables defines additional parameters for the
   indicated PAWS message.  Note that the Requirement column lists FCC,
   not PAWS, requirements/optionality rules.

   The FCC requires registration of "Fixed Devices".  Additionally,
   deviceOwner is required in the registration request:

                   Registration Request (Section 4.4.1)

   +-------------+-------------------+-------------+-------------------+
   | Parameter   | Type              | Requirement | Notes             |
   | Name        |                   |             |                   |
   +-------------+-------------------+-------------+-------------------+
   | deviceOwner | DeviceOwner       | REQUIRED    | For registering   |
   |             | (Section 5.5)     |             | Fixed Devices     |
   +-------------+-------------------+-------------+-------------------+

Top      Up      ToC       Page 73 
                Available Spectrum Request (Section 4.5.1)

   +---------------+-----------------------------+-------------+-------+
   | Parameter     | Type                        | Requirement | Notes |
   | Name          |                             |             |       |
   +---------------+-----------------------------+-------------+-------+
   | deviceDesc    | DeviceDescriptor (Section   | REQUIRED    |       |
   |               | 5.2)                        |             |       |
   +---------------+-----------------------------+-------------+-------+

             Available Spectrum Batch Request (Section 4.5.3)

   +---------------+-----------------------------+-------------+-------+
   | Parameter     | Type                        | Requirement | Notes |
   | Name          |                             |             |       |
   +---------------+-----------------------------+-------------+-------+
   | deviceDesc    | DeviceDescriptor (Section   | REQUIRED    |       |
   |               | 5.2)                        |             |       |
   +---------------+-----------------------------+-------------+-------+

                      DeviceDescriptor (Section 5.2)

   +-------------------+--------+-------------+------------------------+
   | Parameter Name    | Type   | Requirement | Notes                  |
   +-------------------+--------+-------------+------------------------+
   | serialNumber      | string | REQUIRED    | Specifies a device's   |
   |                   |        |             | serial number.  See    |
   |                   |        |             | Section 5.2.           |
   | fccId             | string | REQUIRED    | Specifies a device's   |
   |                   |        |             | FCC certification ID   |
   |                   |        |             | (Section 9.2.2.1).     |
   | fccTvbdDeviceType | string | REQUIRED    | Specifies the FCC      |
   |                   |        |             | Device Type (Section   |
   |                   |        |             | 9.2.2.2) of TV-band    |
   |                   |        |             | white-space device, as |
   |                   |        |             | defined by the FCC     |
   |                   |        |             | rules.                 |
   +-------------------+--------+-------------+------------------------+

Top      Up      ToC       Page 74 
   The following table lists additional requirements for DeviceOwner
   (Section 5.5) parameter values.

                         DeviceOwner (Section 5.5)

   +-----------+-------+-----------------------------------------------+
   | Parameter | Type  | Additional Requirement                        |
   | Name      |       |                                               |
   +-----------+-------+-----------------------------------------------+
   | owner     | vCard | The owner is required to contain the          |
   |           |       | formatted name of an individual or            |
   |           |       | organization using the "fn" property.  When   |
   |           |       | the name is that of an organization, the      |
   |           |       | entry also is required to contain the "kind"  |
   |           |       | property, with a value of "org".              |
   | operator  | vCard | The operator entry is required to contain the |
   |           |       | following properties for the contact person   |
   |           |       | responsible for the device's operation: "fn", |
   |           |       | "adr", "tel", and "email".                    |
   +-----------+-------+-----------------------------------------------+

9.1.2.2.  European Telecommunications Standards Institute (ETSI)

   For the additional parameters that start with the "etsi" prefix, see
   PAWS Parameters Registry Initial Contents (Section 9.2.2) for more
   information.

   Ruleset identifier:  ETSI-EN-301-598-1.1.1

   Specification document(s):  This ruleset refers to the ETSI
      Harmonised Standard [ETSI-EN-301-598] established by ETSI.

   Additional Parameter Requirements

   Each of the following tables defines additional parameters for the
   indicated PAWS message.  Note that the Requirement column lists ETSI,
   not PAWS, requirements/optionality rules.

Top      Up      ToC       Page 75 
   +-------------------------------------------------------------------+
   | Parameter Name                                                    |
   |    Type                                                           |
   |    Requirement                                                    |
   |    Notes                                                          |
   +-------------------------------------------------------------------+
   | serialNumber                                                      |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies a device's serial number (Section 5.2).              |
   |                                                                   |
   | manufacturerId                                                    |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies a device's manufacturer's identifier                 |
   |     (Section 5.2).                                                |
   |                                                                   |
   | modelId                                                           |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies a device's model identifier (Section 5.2).           |
   |                                                                   |
   | etsiEnDeviceType                                                  |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies the device's ETSI device type (Section 9.2.2.3).     |
   |                                                                   |
   | etsiEnDeviceEmissionsClass                                        |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies the device's ETSI device emissions class             |
   |     (Section 9.2.2.4).                                            |
   |                                                                   |
   | etsiEnTechnologyId                                                |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies the device's ETSI technology ID (Section 9.2.2.5).   |
   |                                                                   |
   | etsiEnDeviceCategory                                              |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies the device's ETSI device category (Section 9.2.2.6). |
   +-------------------------------------------------------------------+

Top      Up      ToC       Page 76 
                    AVAIL_SPECTRUM_REQ (Section 4.5.1)

   +-------------+--------+-------------+------------------------------+
   | Parameter   | Type   | Requirement | Notes                        |
   | Name        |        |             |                              |
   +-------------+--------+-------------+------------------------------+
   | requestType | string | OPTIONAL    | Modifies the available-      |
   |             |        |             | spectrum request type.  If   |
   |             |        |             | specified, the only valid    |
   |             |        |             | value is, "Generic Slave",   |
   |             |        |             | and the Database is required |
   |             |        |             | to respond with generic      |
   |             |        |             | operating parameters for any |
   |             |        |             | Slave Device.                |
   +-------------+--------+-------------+------------------------------+

             Available Spectrum Batch Request (Section 4.5.3)

   +-------------+--------+-------------+------------------------------+
   | Parameter   | Type   | Requirement | Notes                        |
   | Name        |        |             |                              |
   +-------------+--------+-------------+------------------------------+
   | requestType | string | OPTIONAL    | Modifies the available-      |
   |             |        |             | spectrum request type.  If   |
   |             |        |             | specified, the only valid    |
   |             |        |             | value is, "Generic Slave",   |
   |             |        |             | and the Database is required |
   |             |        |             | to respond with generic      |
   |             |        |             | operating parameters for any |
   |             |        |             | Slave Device.                |
   +-------------+--------+-------------+------------------------------+

   The following tables define additional requirements for the
   DeviceDescriptor (Section 5.2) and RulesetInfo (Section 5.6)
   parameters that appear in the AVAIL_SPECTRUM_RESP (Section 4.5.2) and
   AVAIL_SPECTRUM_BATCH_RESP (Section 4.5.4) messages.  Note that this
   means the Database is modifying the DeviceDescriptor sent by the
   Master Device to return device-specific restrictions.

Top      Up      ToC       Page 77 
   +-------------------------------------------------------------------+
   | Parameter Name                                                    |
   |    Type                                                           |
   |    Requirement                                                    |
   |    Notes                                                          |
   +-------------------------------------------------------------------+
   | needsSpectrumReport                                               |
   |    boolean                                                        |
   |    REQUIRED                                                       |
   |    The Database is required to set this to true to indicate that  |
   |     the device must report spectrum usage.                        |
   |                                                                   |
   | maxTotalBwHz                                                      |
   |    float                                                          |
   |    REQUIRED                                                       |
   |    Specifies a constraint on total allowed bandwidth.             |
   |                                                                   |
   | maxContiguousBwHz                                                 |
   |    float                                                          |
   |    REQUIRED                                                       |
   |    Specifies a constraint on total allowed contiguous             |
   |     bandwidth.                                                    |
   |                                                                   |
   | etsiEnSimultaneousChannelOpera                                    |
   |    string                                                         |
   |    REQUIRED                                                       |
   |    Specifies a constraint on simultaneous channel operation       |
   |     (Section 9.2.2.7).  If it is not provided, the default value  |
   |      is "0".                                                      |
   +-------------------------------------------------------------------+

                         RulesetInfo (Section 5.6)

   +-------------------+-------+-------------+-------------------------+
   | Parameter Name    | Type  | Requirement | Notes                   |
   +-------------------+-------+-------------+-------------------------+
   | maxLocationChange | float | OPTIONAL    | Specifies a constraint  |
   |                   |       |             | on maximum location     |
   |                   |       |             | changes.                |
   +-------------------+-------+-------------+-------------------------+

Top      Up      ToC       Page 78 
9.2.  PAWS Parameters Registry

   This specification establishes the "PAWS Parameters Registry".

   Additional parameters for inclusion in PAWS requests, responses, or
   sub-messages are registered on the advice of one or more Designated
   Experts, with Specification Required [RFC5226].

   The Designated Expert should avoid duplication, i.e., avoid adding a
   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 should share a common prefix that reflects the ruleset ID.
   The prefix may be omitted, of course, if a parameter has more general
   applicability.  Similarly, when a parameter is not associated with a
   ruleset, the Designated Expert should ensure that the parameter name
   does not have a prefix that is used by existing ruleset parameters
   (e.g., "fcc", "etsi") or that is the initials of an organization that
   has not yet registered anything, but reasonably might.

   The PAWS Parameters Registry includes the following: 'Parameter
   name', 'Parameter usage location', and 'Specification document(s)'.

9.2.1.  Registration Template

   Parameter name:  The name of the parameter (e.g., "example").

   Parameter usage location:  The location(s) where the parameter can be
      used.  The possible locations are the named structures defined in
      "Protocol Functionalities" (Section 4) and "Protocol Parameters"
      (Section 5).

   Specification document(s):  Reference to the document that specifies
      the parameter, preferably including a URI that can be used to
      retrieve a copy of the document.  An indication of the relevant
      sections also may be included, but is not required.

9.2.2.  Initial Registry Contents

   The PAWS Parameters Registry enables protocol extensibility to
   support any regulatory domain and ruleset.  The initial contents of
   the registry, however, include only FCC-specific and ETSI-specific
   entries, because, as of this writing, they are the only regulatory
   domains that have established rules.  There is no intent to restrict
   the protocol to any particular set of authorities.

   The initial contents of the PAWS Parameters Registry are listed
   below; each section corresponds to a row of the registry.

Top      Up      ToC       Page 79 
9.2.2.1.  FCC ID

   Parameter name:  fccId

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  This document.  Specifies the device's
      FCC certification identifier.  A valid FCC ID is limited to 19
      characters in the ASCII value range, as proposed in FCC
      Administration Topics Review [FCC-Review-2012-10].  For the
      purposes of the PAWS protocol, the maximum length of the fccId
      value is 32 octets.

9.2.2.2.  FCC Device Type

   Parameter name:  fccTvbdDeviceType

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  This document.  Specifies the TV-band
      white-space device type, as defined by the FCC.  Valid values are
      "FIXED", "MODE_1", and "MODE_2".

9.2.2.3.  ETSI Device Type

   Parameter name:  etsiEnDeviceType

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the white-space device type, as
      defined by the ETSI Harmonised Standard [ETSI-EN-301-598].  Valid
      values are single-letter strings, such as "A", "B", etc.  Consult
      the documentation for details about the device types.

9.2.2.4.  ETSI Device Emissions Class

   Parameter name:  etsiEnDeviceEmissionsClass

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the white-space device
      emissions class, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598], that characterizes the out-of-block emissions
      of the device.  The values are represented by numeric strings,
      such as "1", "2", "3", etc.  Consult the documentation for details
      about emissions classes.

Top      Up      ToC       Page 80 
9.2.2.5.  ETSI Technology Identifier

   Parameter name:  etsiEnTechnologyId

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the white-space device
      technology identifier, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598].  The maximum length of the string value is 64
      octets.  Consult the documentation for valid values.

9.2.2.6.  ETSI Device Category

   Parameter name:  etsiEnDeviceCategory

   Parameter usage location:  DeviceDescriptor (Section 5.2)

   Specification document(s):  Specifies the white-space device
      category, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598].  Valid values are the strings "master" and
      "slave".  It is case insensitive.

9.2.2.7.  ETSI Simultaneous Channel Operation Restriction

   Parameter name:  etsiEnSimultaneousChannelOperationRestriction

   Parameter usage location:  SpectrumSpec (Section 5.9)

   Specification document(s):  Specifies the constraint on the device
      maximum total EIRP, as defined by the ETSI Harmonised Standard
      [ETSI-EN-301-598].  The values are represented by numeric strings,
      such as "0", "1", etc.  Consult the documentation for the
      specification of the power constraint corresponding to each
      parameter value.

9.3.  PAWS Error Code Registry

   This specification establishes the "PAWS Error Code Registry".

   Additional error codes for inclusion in PAWS error messages are
   registered on the advice of one or more Designated Experts, with
   Specification Required [RFC5226].

   Error codes are intended to be used for automated error handling by
   devices.  Before approval, the Designated Expert should consider
   whether a device would handle the new error code differently from an

Top      Up      ToC       Page 81 
   existing error code, or whether the difference could be communicated
   effectively to the end-user via the "reason" parameter of the Error
   (Section 5.17) object.

   The PAWS Error Code Registry includes the following: 'Code', 'Name',
   'Description and Additional Parameters', and 'Specification
   Document(s)'.

9.3.1.  Registration Template

   Code:  Integer value of the error code.  The value MUST be an
      unassigned value in the range -32768 to 32767, inclusive.

   Name:  Name of the error.

   Description and Additional Parameters:  Description of the error and
      its associated parameters, if any.  It also lists additional
      parameters that are returned in the data portion of the error (see
      Section 5.17).  New parameters MUST be registered separately in
      the PAWS Parameters Registry, as described by Section 9.2.

9.3.2.  Initial Registry Contents

   Initial registry contents are defined in the Error Codes
   Table (Table 1).

   The registry will also include the error-code categories describing
   -100s, -200s, and -300s as a note (see "Error Codes" (Section 5.17)).

10.  Security Considerations

   PAWS is a protocol whereby a Master Device requests a schedule of
   available spectrum at its location (or location of its Slave Devices)
   before it (they) can operate using those frequencies.  Whereas the
   information provided by the Database must be accurate and conform to
   the applicable ruleset, the Database cannot enforce, through the
   protocol, that a client device uses only the spectrum it provided.
   In other words, devices can put energy in the air and cause
   interference without asking the Database.  Hence, PAWS security
   considerations do not include protection against malicious use of the
   white-space spectrum.  For more detailed information on specific
   requirements and security considerations associated with PAWS, see
   "Protocol to Access White-Space (PAWS) Databases: Use Cases and
   Requirements" [RFC6953].

Top      Up      ToC       Page 82 
   By using PAWS, the Master Device and the Database expose themselves
   to the following risks:

   o  Accuracy: The Master Device receives incorrect spectrum-
      availability information.

   o  Privacy:

      *  An unauthorized entity intercepts identifying data for the
         Master Device or its Slave Devices, such as serial number and
         location.

      *  Where Databases are required to take device registrations and/
         or maintain request logs, there could be unauthorized access to
         such information.

   Protection from these risks depends on the success of the following
   steps:

   1.  The Master Device must determine the address of a proper
       Database.

   2.  The Master Device must connect to the proper Database.

   3.  The Database must determine or compute accurate spectrum-
       availability information.

   4.  PAWS messages must be transmitted unmodified between the Database
       and the Master Device.

   5.  PAWS messages must be encrypted between the Database and the
       Master Device to prevent exposing private information.

   6.  For a Slave Device, the spectrum-availability information also
       must be transmitted unmodified and securely between the Master
       Device and the Slave Device.

   7.  When a Listing Server is required, any attack that would prevent
       reaching a Listing Server would result in all devices relying on
       that Listing Server ceasing their use of any white space.

   8.  No future extensions to PAWS can allow the return of sensitive
       information, such as device information or logs.

   9.  The Database must not allow unauthorized access to device
       information and request logs and should publish and implement
       privacy policies regarding their use.

Top      Up      ToC       Page 83 
   Of these, only steps 1, 2, 4, 5, and 8 are within the scope of this
   document.  This document addresses step 1 by allowing static
   provisioning of one or more trusted Databases; dynamic provisioning
   is out of scope.  Step 3 is dependent on specific database
   implementations and rulesets and is outside the scope of this
   document.  Step 6 requires a protocol between master and slave
   devices and is thus outside the scope of this document.

   Use of "HTTP Over TLS" [RFC2818], assuming the PKI used is not
   compromised, ensures steps 2, 4, and 5, as detailed in the following
   sections:

   o  "Assurance of Proper Database" (Section 10.1)

   o  "Protection against Modification" (Section 10.2)

   o  "Protection against Eavesdropping" (Section 10.3)

   Any specification for an alternate transport MUST define mechanisms
   that ensure each of these steps.

   In addition to the privacy risks described above, information
   provided in DeviceDescriptor (Section 5.2) and DeviceOwner
   (Section 5.5), along with device location, may allow a database
   administrator to track the activity and location of a device and its
   user over time.  Risks of secondary use of such tracking information,
   including sharing with third parties, require out-of-band mitigation,
   such as public statements or contractual terms.  Furthermore, while
   it is understandable that regulators require DeviceOwner information
   for higher-power fixed white-space devices, for privacy concerns,
   regulators should not require DeviceOwner information for mobile
   devices.  Similarly, regulators should require, and implementations
   should provide, device location at a level of granularity only as
   precise as necessary to support accurate database responses.

10.1.  Assurance of Proper Database

   This document assumes that the Database is contacted using a domain
   name or an IP address.  Using HTTP over TLS, the Database
   authenticates its identity, either as a domain name or IP address, to
   the Master Device by presenting a certificate containing that
   identifier as a "subjectAltName" (i.e., as a dNSName or IP address).
   If the Master Device has external information as to the expected
   identity or credentials of the proper Database (e.g., a certificate
   fingerprint), checks of the subjectAltName MAY be omitted.  Note that
   in order for the presented certificate to be valid at the client, the
   client must be able to validate the certificate.  In particular, the
   validation path of the certificate must end in one of the client's

Top      Up      ToC       Page 84 
   trust anchors, even if that trust anchor is the Database's
   certificate.  A Master Device should allow for the fact that a
   Database can change its Certification Authorities (CAs) over time.

10.2.  Protection against Modification

   To prevent a PAWS response message from being modified en route,
   messages must be transmitted over an integrity-protected channel.
   Using HTTP over TLS, the channel will be protected by appropriate
   cipher suites.

10.3.  Protection against Eavesdropping

   Using HTTP over TLS, messages protected by appropriate cipher suites
   are also protected from eavesdropping or otherwise unrestricted
   reading by unauthorized parties en route.

10.4.  Client Authentication Considerations

   Although the Database can inform a device of available spectrum it
   can use, the Database cannot enforce that the Master Device uses only
   (or any of) those frequencies.  Indeed, a malicious device can
   operate without ever contacting a Database.  Note also that, whereas
   a malicious device may send fraudulent SPECTRUM_USE_NOTIFY
   (Section 4.5.5) messages, in the regulatory domains that have
   established rules, such notifications do not change the available-
   spectrum answers, so no harm can result from such messages.
   Consequently, client authentication is not required for the core PAWS
   (although it may be required by specific regulatory domains).

   Depending on a prior relationship between a Database and Master
   Device, the Database MAY require client authentication.  TLS provides
   client authentication, but there are some considerations:

   o  The Database must nominate acceptable CAs, and the Master Device
      must have a certificate rooted at one of those CAs.

   o  As indicated in Section 3.2 of "HTTP Over TLS" [RFC2818], the TLS
      client authentication procedure only determines that the device
      has a certificate chain rooted in an appropriate CA (or a self-
      signed certificate).  The Database would not know what the client
      identity ought to be, unless it has some external source of
      information.  Distribution and management of such information,
      including revocation lists, are outside the scope of this
      document.

Top      Up      ToC       Page 85 
   o  Authentication schemes are secure only to the extent that secrets
      or certificates are kept secure.  When there are a vast number of
      deployed devices using PAWS, the possibility that device keys will
      not leak becomes small.  Implementations should consider how to
      manage the system in the eventuality that there is a leak.

11.  References

11.1.  Normative References

   [JSON-RPC]
              "JSON-RPC 2.0 Specification",
              <http://www.jsonrpc.org/specification>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <http://www.rfc-editor.org/info/rfc3339>.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <http://www.rfc-editor.org/info/rfc5077>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

Top      Up      ToC       Page 86 
   [RFC5491]  Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              Presence Information Data Format Location Object (PIDF-LO)
              Usage Clarification, Considerations, and Recommendations",
              RFC 5491, DOI 10.17487/RFC5491, March 2009,
              <http://www.rfc-editor.org/info/rfc5491>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011,
              <http://www.rfc-editor.org/info/rfc6350>.

   [RFC7095]  Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
              DOI 10.17487/RFC7095, January 2014,
              <http://www.rfc-editor.org/info/rfc7095>.

   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
              2014, <http://www.rfc-editor.org/info/rfc7159>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

11.2.  Informative References

   [ETSI-EN-301-598]
              European Telecommunication Standards Institute (ETSI),
              "ETSI EN 301 598 (V1.1.1): White Space Devices (WSD);
              Wireless Access Systems operating in the 470 MHz to 790
              MHz TV broadcast band; Harmonized EN covering the
              essential requirements of article 3.2 of the R&TTE
              Directive", April 2014, <http://www.etsi.org/deliver/
              etsi_en/301500_301599/301598/01.01.01_60/
              en_301598v010101p.pdf>.

   [FCC-CFR47-15H]
              U. S. Government, "Electronic Code of Federal Regulations,
              Title 47, Part 15, Subpart H: Television Band Devices",
              December 2010, <http://www.ecfr.gov/cgi-bin/
              text-idx?rgn=div6&view=text&node=47:1.0.1.1.16.8>.

Top      Up      ToC       Page 87 
   [FCC-Review-2012-10]
              Federal Communications Commission, "Administration Topics
              Review", October 2012,
              <http://transition.fcc.gov/bureaus/oet/ea/presentations/
              files/oct12/2b-TCB-Admin-Issues-Oct-2012-GT.pdf>.

   [ISO3166-1]
              "Country Codes",
              <http://www.iso.org/iso/country_codes.htm>.

   [RFC6953]  Mancuso, A., Ed., Probasco, S., and B. Patil, "Protocol to
              Access White-Space (PAWS) Databases: Use Cases and
              Requirements", RFC 6953, DOI 10.17487/RFC6953, May 2013,
              <http://www.rfc-editor.org/info/rfc6953>.

   [RFC7459]  Thomson, M. and J. Winterbottom, "Representation of
              Uncertainty and Confidence in the Presence Information
              Data Format Location Object (PIDF-LO)", RFC 7459,
              DOI 10.17487/RFC7459, February 2015,
              <http://www.rfc-editor.org/info/rfc7459>.

   [WGS-84]   National Imagery and Mapping Agency, "Department of
              Defense World Geodetic System 1984, Its Definition and
              Relationships with Local Geodetic Systems", NIMA TR8350.2,
              Third Edition, Amendment 1, January 2000,
              <http://earth-info.nga.mil/GandG/publications/tr8350.2/
              tr8350_2.html>.

Top      Up      ToC       Page 88 
Appendix A.  Database Listing Server Support

   As discussed in "Database Discovery" (Section 4.1), some regulatory
   domains support the preconfiguration of devices with the URI of a
   listing server, to which devices can connect to obtain a list of
   Databases certified by the regulatory domain.  Regulatory domains may
   require the device to periodically contact the Database Listing
   Server to validate and/or update its list of certified Databases.  If
   the device is unable to validate its list of certified Databases
   within the required period, regulatory rules may require the device
   to treat this inability as equivalent to the device having no
   available spectrum.

   A sample JSON response from a Database Listing Server might be
   represented as follows:

   {
     "lastUpdateTime": "2014-06-28T10:00:00Z",
     "maxRefreshMinutes": 1440
     "dbs": [
       {
         "name": "Some Operator",
         "uris": [
           {
             "uri": "https://example.some.operator.com",
             "protocol": "paws"
           },
           ...
         ]
       },
       ...
     ]
   }

   The parameters in this sample message are:

   lastUpdateTime:  The time at which the database entries were last
      updated.

   maxRefreshMinutes:  The maximum interval, expressed in minutes, that
      is allowed between device requests to the Database Listing Server.

   dbs:  A list of entries for certified Databases, each containing the
      following

      name:  The name of the database operator.

Top      Up      ToC       Page 89 
      uris:  One or more URIs for each Database, allowing a Database to
         support more than one protocol.

      uri, protocol:  Each protocol supported by a certified Database is
         associated with a separate URI (PAWS protocol URI shown).

Acknowledgments

   The authors gratefully acknowledge the contributions of: Gabor Bajko,
   Ray Bellis, Teco Boot, Nancy Bravin, Rex Buddenberg, Gerald
   Chouinard, Stephen Farrell, Michael Fitch, Joel M. Halpern, Daniel
   Harasty, Michael Head, Jussi Kahtava, Kalle Kulsmanen, Warren Kumari,
   Paul Lambert, Andy Lee, Anthony Mancuso, Basavaraj Patil, Scott
   Probasco, Brian Rosen, Andy Sago, Peter Stanforth, John Stine, and
   Juan Carlos Zuniga.

Contributors

   This document draws heavily from draft-das-paws-protocol and
   draft-wei-paws-framework.  The editor would like to specifically call
   out and thank the contributing authors of those two documents.

      Donald Joslyn
      Spectrum Bridge Inc.
      1064 Greenwood Blvd.
      Lake Mary, FL  32746
      United States
      EMail: d.joslyn@spectrumbridge.com


      Xinpeng Wei
      Huawei
      Phone: +86 13436822355
      EMail: weixinpeng@huawei.com

Top      Up      ToC       Page 90 
Authors' Addresses

   Vincent Chen (editor)
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA  94043
   United States

   EMail: vchen@google.com


   Subir Das
   Applied Communication Sciences
   150 Mount Airy Road
   Basking Ridge, NJ  07920
   United States

   EMail: sdas@appcomsci.com


   Lei Zhu
   Huawei

   Phone: +86 13910157020
   EMail: lei.zhu@huawei.com


   John Malyar
   iconectiv (formerly Telcordia Interconnection Solutions)
   444 Hoes Lane/RRC 4E1106
   Piscataway, NJ  08854
   United States

   EMail: jmalyar@iconectiv.com


   Peter J. McCann
   Huawei
   400 Crossing Blvd, 2nd Floor
   Bridgewater, NJ  08807
   United States

   Phone: +1 908 541 3563
   EMail: peter.mccann@huawei.com