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
