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
