Hello Scott,
I understand your point. But I want to keep things simple. The
P.* requirements are for the protocol, it MUST support optional
variables.
The O.* requirements explain how these are used. This is the MAY,
right?
Having performed some tests today with an emergency responders
network, I saw some high traffic load. Something like this:
<self_explaining_variable_name>
1
<\self_explaining_variable_name>
I could think of an efficiency requirement, for the rapid deployed
network use case.
Thanks, Teco
Op 27 feb. 2012, om 14:32 heeft <[email protected]>
<[email protected]> het volgende geschreven:
> Hi Teco,
>
> If we look at P.9 and P.10 together, P.9 says that registration is a MUST
> -- the protocol supports registration without question. P.10 says the
> signaling for registration MAY contain any of several variables (also
> allows more variables to be included if required by local regulations).
> The list currently identifies all variables required for registration in
> the US. Now if we look at the Data Model requirements, each variable
> identified that the registration service MAY contain (these are in D.5,
> D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The protocol
> MUST support registration, and the Data Model in the protocol MUST support
> the variables identified for registration service.
>
> The current use of MUST in P.9 and MAY in P.10 has the effect that WSDs in
> the US are allowed to register (because the protocol supports
> registration) and are allowed to use the variables defined by the FCC
> (because the registration signaling MAY include those variables). This
> also has the effect that WSDs in the UK (or elsewhere in the world) are
> allowed to register if this is a local requirement (because the protocol
> supports registration) and are allowed to use (or not use) the variables
> defined by the FCC (because the registration signaling MAY include those
> variables). Nothing to prevent adding more variables if needed by Ofcom,
> IDA, etc...
>
> Another possibility is to change the wording of P.10 to read
> P.10: The registration signaling MUST include the following optional
> variables: the Device ID, manufacturer¹s serial number, device location,
> device antenna characteristic information, name of individual or business
> that owns the device, name, address, email address and phone number of a
> contact person who is responsible for device operation.
>
> What do you think?
>
> Kind Regards,
> Scott
>
>
>
>
>
>
> On 2/26/12 3:41 PM, "ext Teco Boot" <[email protected]> wrote:
>
>> Hi Scott,
>>
>> I still think it is a MUST for the protocol, and a MAY for usage.
>>
>> Thanks, Teco
>>
>> Op 24 feb. 2012, om 19:58 heeft <[email protected]>
>> <[email protected]> het volgende geschreven:
>>
>>> Hello Teco,
>>>
>>> Since PAWS is a global standard, registration for all regulatory domains
>>> must be supported. While the FCC does require all of the variables
>>> listed
>>> in P.10, other regulatory domains may not require each of those
>>> variables.
>>> So for requirements on the protocol, using MAY enables the FCC to
>>> require
>>> these variables while allowing other regulators to select a subset, or
>>> even different, variables.
>>>
>>> With this explanation, are you okay with MAY in P.10?
>>>
>>> Kind Regards,
>>> Scott
>>>
>>>
>>>
>>> On 2/22/12 1:34 AM, "ext Teco Boot" <[email protected]> wrote:
>>>
>>>> Scott, Ray,
>>>>
>>>> The P.* are mostly MUST requirements for the protocol. That's fine.
>>>> Except P.10, this is a MAY operational requirement. The protocol
>>>> MUST support it.
>>>>
>>>> I'm fine with the rest of it.
>>>>
>>>> Is noted somewhere that we (IETF) do our best to support as many
>>>> regulator rules as possible, and leave setting up requirements for
>>>> actual deployment up to the mandated authorities? This makes the
>>>> O.* requirements informational.
>>>>
>>>> Thanks, Teco
>>>>
>>>>
>>>> Op 22 feb. 2012, om 00:53 heeft <[email protected]>
>>>> <[email protected]> het volgende geschreven:
>>>>
>>>>> Hello All,
>>>>>
>>>>> I have revised Section 6 of the I-D which describes the Data Model
>>>>> Requirements, Protocol Requirements and Operational Requirements. This
>>>>> includes the requirements from the threat model
>>>>> (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html).
>>>>>
>>>>> The requirements are ordered "top down" to follow the previous
>>>>> sections
>>>>> of
>>>>> the document: requirements derived from discovery are followed by
>>>>> requirements derived from registration are followed by requirements
>>>>> derived from hotspot, etc...
>>>>>
>>>>> Please review the proposed text, we hope to have your comments by Feb
>>>>> 28th.
>>>>>
>>>>> Kind Regards,
>>>>>
>>>>> Raj & Scott
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> D. Data Model Requirements:
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to discovery function</Ed. Note>
>>>>> D.1: The Data Model MUST support specifying the location of the WSD,
>>>>> the
>>>>> uncertainty in meters, the height & its uncertainty, and confidence in
>>>>> percentage for the location determination. The Data Model MUST support
>>>>> both North American Datum of 1983 and WGS84.
>>>>>
>>>>>
>>>>> D.2: The Data Model MUST support specifying the URI address of a white
>>>>> space database.
>>>>>
>>>>>
>>>>> D.3: The Data Model MUST support specifying the URI address of a
>>>>> national
>>>>> listing service.
>>>>>
>>>>>
>>>>> D.4: The Data Model MUST support specifying regulatory domain and its
>>>>> corresponding data requirements.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to registration function</Ed. Note>
>>>>> D.5: The Data Model MUST support specifying an ID of the transmitter
>>>>> device. This ID would contain the ID of the transmitter device that
>>>>> has
>>>>> been certified by a regulatory body for its regulatory domain. The
>>>>> Data
>>>>> Model MUST support a device class.
>>>>>
>>>>>
>>>>>
>>>>> D.6: The Data Model MUST support specifying a manufacturer¹s serial
>>>>> number
>>>>> for a master device.
>>>>>
>>>>>
>>>>> D.7: The Data Model MUST support specifying the antenna and radiation
>>>>> related parameters of the device, such as:
>>>>>
>>>>> - antenna height
>>>>>
>>>>> - antenna gain
>>>>>
>>>>> - maximum output power, EIRP (dBm)
>>>>>
>>>>> - antenna radiation pattern (directional dependence
>>>>> of the strength of the radio signal from the antenna)
>>>>>
>>>>> - spectrum mask with lowest and highest possible frequency
>>>>>
>>>>> - spectrum mask in dBr from peak transmit power in EIRP,
>>>>> with specific power limit at any frequency linearly
>>>>> interpolated between adjacent points of the spectrum mask
>>>>> measurement resolution bandwidth for EIRP measurements.
>>>>>
>>>>>
>>>>>
>>>>> D.8: The Data Model MUST support specifying owner and operator contact
>>>>> information for a transmitter. This includes the name of the
>>>>> transmitter
>>>>> owner, name of transmitter operator, postal address, email address and
>>>>> phone number of the transmitter operator.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to hotspot use case</Ed. Note>
>>>>> D.9: The Data Model MUST support specifying a list of available
>>>>> channels.
>>>>> The Data Model MUST support specification of this information by
>>>>> channel
>>>>> numbers and by start and stop frequencies. The Data Model MUST
>>>>> support a
>>>>> channel availability schedule and maximum power level for each channel
>>>>> in
>>>>> the list.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to mobility use case</Ed. Note>
>>>>> D.10: The Data Model MUST support specifying channel availability
>>>>> information for a single location and an area (e.g. a polygon defined
>>>>> by
>>>>> multiple location points or a geometric shape such as a circle).
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> P. Protocol Requirements:
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to discovery function</Ed. Note>
>>>>> P.1: The protocol MUST provide a message sequence for the master
>>>>> device
>>>>> to
>>>>> discover a white space database that provides service at its current
>>>>> location.
>>>>>
>>>>>
>>>>> P.2: The protocol MUST support access of a database directly. The
>>>>> protocol
>>>>> MUST support access of a database using a listing approved by a
>>>>> national
>>>>> regulator.
>>>>>
>>>>>
>>>>> P.3: The protocol MUST support determination of regulatory domain
>>>>> governing its current location.
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to threat model</Ed. Note>
>>>>>
>>>>>
>>>>> P.4: The protocol MUST provide the ability for the database to
>>>>> authenticate the master device.
>>>>>
>>>>>
>>>>> P.5: The protocol MUST provide the ability for the master device to
>>>>> verify
>>>>> the authenticity of the database with which it is interacting.
>>>>>
>>>>>
>>>>> P.6: The messages sent by the master device to the database MUST be
>>>>> integrity protected.
>>>>>
>>>>>
>>>>> P.7: The messages sent by the database to the master device MUST be
>>>>> integrity protected.
>>>>>
>>>>>
>>>>> P.8: The protocol MUST provide the capability for messages sent by the
>>>>> master device and database to be encrypted.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to registration function</Ed. Note>
>>>>> P.9: The protocol MUST support the master device registering with the
>>>>> database.
>>>>>
>>>>>
>>>>> P.10: The registration signaling MAY include the Device ID,
>>>>> manufacturer¹s
>>>>> serial number, device location, device antenna characteristic
>>>>> information,
>>>>> name of individual or business that owns the device, name, address,
>>>>> email
>>>>> address and phone number of a contact person who is responsible for
>>>>> device
>>>>> operation.
>>>>>
>>>>>
>>>>> P.11: The protocol MUST support a registration acknowledgement
>>>>> including
>>>>> appropriate result codes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to hotspot use case</Ed. Note>
>>>>> P.12: The protocol MUST support a channel query request from the
>>>>> master
>>>>> device to the database. The channel query request message MUST include
>>>>> parameters as required by local regulatory requirement. These
>>>>> parameters
>>>>> MAY include device location, device ID, manufacturer¹s serial number,
>>>>> and
>>>>> antenna characteristic information.
>>>>>
>>>>>
>>>>> P.13: The protocol MUST support a channel query response from the
>>>>> database
>>>>> to the master device. The channel query response message MUST include
>>>>> parameters as required by local regulatory requirement. These
>>>>> parameters
>>>>> MAY include available channels, duration of time for their use,
>>>>> associated
>>>>> maximum power levels, any additional sensing requirements.
>>>>>
>>>>>
>>>>> P.14: The protocol MUST support a channel query request from the slave
>>>>> device to the master device. The channel query request message MUST
>>>>> include parameters as required by local regulatory requirement. These
>>>>> parameters MAY include device ID and slave device location.
>>>>>
>>>>>
>>>>> P.15: The protocol MUST support a validation request from the master
>>>>> to
>>>>> the database to validate a slave device. The validation request MUST
>>>>> include the slave device ID.
>>>>>
>>>>>
>>>>> P.16: The protocol MUST support a validation response from the
>>>>> database
>>>>> to
>>>>> the master. The validation response MUST include a response code.
>>>>>
>>>>>
>>>>> P.17: The protocol MUST support a channel query response from the
>>>>> master
>>>>> device to the slave device. The channel query response message MUST
>>>>> include parameters as required by local regulatory requirement,
>>>>> including
>>>>> a response code and sufficient information to decode an enabling
>>>>> signal.
>>>>>
>>>>>
>>>>> P.18: The protocol MUST support an enabling signal sent from the
>>>>> master
>>>>> to
>>>>> the slave. This signal MUST allow the slave device to validate that a
>>>>> previously received available channel list is still valid or not. This
>>>>> signal MUST be encoded to allow the slave device to determine the
>>>>> identity
>>>>> if the sending master device.
>>>>>
>>>>>
>>>>>
>>>>> P.19: The protocol between the master device and the database MUST
>>>>> support
>>>>> the capability to change channel availability lists on short notice.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to mobility use case</Ed. Note>
>>>>> P.20: The protocol between the master device and the database MUST
>>>>> support
>>>>> a channel availability request which specifies a geographic location
>>>>> as
>>>>> an
>>>>> area as well as a point.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> O. Operational Requirements:
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to discovery function</Ed. Note>
>>>>>
>>>>> O.1: The database and the master device MUST be connected to the
>>>>> Internet.
>>>>>
>>>>>
>>>>> O.2: A master device MUST be able to determine its location including
>>>>> uncertainty and confidence level. A fixed master device MAY use a
>>>>> location
>>>>> programmed at installation or have the capability determine its
>>>>> location
>>>>> to the required accuracy. A mobile master device MUST have the
>>>>> capability
>>>>> to determine its location to the required accuracy.
>>>>>
>>>>>
>>>>> O.3: The master device MUST identify a database for use. The master
>>>>> device
>>>>> MAY select a database for service by discovery at runtime or the
>>>>> master
>>>>> device MAY select a database for service by means of a pre-programmed
>>>>> URI
>>>>> address.
>>>>>
>>>>>
>>>>> O.4: The master device MUST implement at least one connection method
>>>>> to
>>>>> access the database. The master device MAY contact a database directly
>>>>> for
>>>>> service (e.g. as defined by FCC) or the master device MAY contact a
>>>>> listing server first followed by contact to a database (e.g. As
>>>>> defined
>>>>> by
>>>>> Ofcom).
>>>>>
>>>>>
>>>>> O.5: The master device MUST obtain an indication the regulatory domain
>>>>> governing operation at its current location, i.e. the master device
>>>>> MUST
>>>>> know if it operates under regulations from FCC, Ofcom, etcŠ
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to registration function</Ed. Note>
>>>>> O.6: The master device MAY register with the database according to
>>>>> local
>>>>> regulatory policy. Not all master devices will be required to
>>>>> register.
>>>>> Specific events will initiate registration, these events are
>>>>> determined
>>>>> by
>>>>> regulator policy (e.g. at power up, after movement, etcŠ).
>>>>>
>>>>>
>>>>> O.7: The master device MUST register with its most current and
>>>>> up-to-date
>>>>> information.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to hotspot use case</Ed. Note>
>>>>> O.8: A master device MUST query the database for the available
>>>>> channels
>>>>> based on its current location before starting radio transmission in
>>>>> white
>>>>> space. Parameters provided to the database MAY include device
>>>>> location,
>>>>> accuracy of the location, antenna characteristic information, device
>>>>> identifier of any slave device requesting channel information.
>>>>>
>>>>>
>>>>> O.9: The database MUST respond to an available channel list request
>>>>> from
>>>>> an authenticated and authorized device and MAY also provide time
>>>>> constraints, maximum output power, start and stop frequencies for each
>>>>> channel in the list and any additional requirements for sensing.
>>>>>
>>>>>
>>>>> O.10: After connecting to a master device¹s radio network a slave
>>>>> device
>>>>> MUST query the master device for a list of available channels. The
>>>>> slave
>>>>> MUST include parameters required by local regulatory policy, e.g.
>>>>> device
>>>>> ID, device location.
>>>>>
>>>>>
>>>>> O.11: According to local regulatory policy, the master device MAY
>>>>> query
>>>>> the database with parameters received from the slave device.
>>>>>
>>>>>
>>>>> O.12: The database MUST respond to a query from the master device
>>>>> containing parameters from a slave device.
>>>>>
>>>>>
>>>>> O.13: After the master device has received a response from the
>>>>> database,
>>>>> the master device MUST respond to the slave device. If all regulatory
>>>>> requirements are met the response will contain an available channel
>>>>> list.
>>>>> If regulatory requirements are not met, the response MUST contain at
>>>>> least
>>>>> a response code.
>>>>>
>>>>>
>>>>> O.14: If a master device has provided an available channel list to a
>>>>> slave
>>>>> device the master device MAY send a periodic enabling signal to allow
>>>>> the
>>>>> slave device to confirm it is still within reception range of the
>>>>> master
>>>>> device.
>>>>>
>>>>>
>>>>> O.15: The enabling signal MUST be encoded so that the receiving slave
>>>>> can
>>>>> determine the identity of the sending master.
>>>>>
>>>>>
>>>>> O.16: Periodically, at an interval according to local regulations, the
>>>>> slave device MUST either receive and enabling signal or MUST
>>>>> successfully
>>>>> repeat the channel request process or MUST cease transmission on the
>>>>> channel.
>>>>>
>>>>>
>>>>> O.17: A master device MUST repeat the query the database for the
>>>>> available
>>>>> channels as often as required by the regulation (eg, FCC requires once
>>>>> per
>>>>> day) to verify that the operating channels continue to remain
>>>>> available.
>>>>>
>>>>>
>>>>> O.18: A master device which changes its location more than a threshold
>>>>> distance specified by local regulatory policy during its operation,
>>>>> MUST
>>>>> query the database for available operating channels each time it moves
>>>>> more than the threshold distance (e.g., FCC specifies 100m) from the
>>>>> location it previously made the query.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to wran use case</Ed. Note>
>>>>> O.19: If slave devices change their location during operation by more
>>>>> than
>>>>> a limit specified by the local regulator, the slave device MUST query
>>>>> the
>>>>> master device for available operating channels.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to rapid deployed network use case</Ed.
>>>>> Note>
>>>>> O.20: According to local regulator policy, a master device may
>>>>> contact a
>>>>> database via proxy service of another master device.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to mobility use case</Ed. Note>
>>>>> O.21: A master device MUST be able to query the whitespace database
>>>>> for
>>>>> channel availability information for a specific expected coverage area
>>>>> around its current location.
>>>>>
>>>>>
>>>>>
>>>>> <Ed. Note>requirements related to threat model</Ed. Note>
>>>>> O.22: A Master device MAY not include its identity in
>>>>> messages sent to the database when not required by the regulatory
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> paws mailing list
>>>>> [email protected]
>>>>> https://www.ietf.org/mailman/listinfo/paws
>>>>
>>>
>>
>
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
