Hi Vince,
I have a question about the "Interaction model". In your description,
the DB will authenticate the device, but
sometimes the device may also needs to authenticate the DB. So maybe a mutual
authentication need to be considered.
--Xinpeng
From: [email protected] [mailto:[email protected]] On Behalf Of Vincent
Chen
Sent: Wednesday, January 16, 2013 9:30 AM
To: [email protected]
Subject: [paws] PAWS Protocol: Extensibility
All,
I'd like to propose the following for addressing the extensibility of the
protocol.
Regulatory rules (roughly) fall under three areas:
* Database-only rules, such as how spectrum availability must be computed
* Device-only rules that govern its behavior, e.g.,
* Maximum-power levels that depend on how many channels the Device
chooses to use
* Conditions under which the Device must contact the Database
* Rules that impact both, such as,
* Device parameters that are needed to determine spectrum availability
* Spectrum-availability information that must be provided by the Database
* Spectrum utilization reporting (in jurisdictions that require it)
The following proposals assumes that it will not be practical to have the
Database be responsible for communicating Device-only rules to the devices,
because:
* It is impractical to encode all device behavior via a set of declarative
parameters
* The device will be subject to a certification process to determine
correct device behavior for each set of regulatory rules
Interaction model
The Device must include a "Device Descriptor" with each request to the
Database. The descriptor contains fields that identify the device, its
configuration, its certification tags, and any other parameters required by
regulators, such as device type, device class, etc.
1. The Device makes a request with as many of the Device Descriptor fields
as it chooses to populate, plus its location
2. The Database determines if all required parameters are provided. If not,
it returns an error with a list of the missing parameters.
* The list of missing parameters may depend on the certification tags
provided by the Device
* If certification tags are specified, but the Database does not allow
any of them, it returns a UNAUTHORIZED error
1. The Device may make the request again with the missing parameters. If the
Device cannot supply the missing parameters, it will not be able to use the
Database.
2. When the request is valid, the Database includes in its response the
certification tag that corresponds to the applicable rule set.
A "certification tag" represents the certification a device has been certified
by a certification body (does not necessarily have to be a regulator?). A
device may be configured with multiple certification tags.
Valid values for the certification tag, as well as valid Device Descriptor
fields, will be extensible via appropriate IANA tables.
NOTE: In order for new regulators to leverage existing devices to operate
within their jurisdictions, regulators might be motivated adopt existing
certifications, rather than defined create new rules and new certification
processes. If that is true, there should not be a proliferation of
certification tags.
Is something like this workable?
--
-vince
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
