All,
I've updated the draft to incorporate the comments raised on the list in
response to version 04.
- Clarified what should happen if device loses contact with Listing Server
- Clarified that if a Database indicates a database-change via
DbUpdateSpec, the Device should
only replace that database's entry with the alternate databases.
Other Changes from 04:
o Add "masterDeviceDesc" parameter to the available-spectrum
requests to allow both Master and Slave device descriptors when
the Master is making the request on behalf of a Slave.
o Add "requestType" parameter to the available-spectrum requests to
support requesting generic operating parameters for any Slave
Device.
o Add DbUpdateSpec as optional parameter to all response messages
and to the error response to allow a Device to detect a database
change at any stage of the control flow.
o For the OUTSIDE_COVERAGE error, added ability to return a list of
alternate databases
o Explicitly allow JSON-RPC v2.0 and v1.0 encodings
o Relaxed language that state, "MUST stop operation" to "MUST cease
use of spectrum under rules for database-managed spectrum". I.e.,
the device may have other fallback strategies allowed by
regulators.
Diff:
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-paws-protocol-04.txt&url2=http://tools.ietf.org/id/draft-ietf-paws-protocol-05.txt
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
