Hi Teco, We could change O.7 to something like:
O.7: The master device MUST register with its most current and up-to-date information, and MUST include all variables mandated by local regulator policy. Would this work? Kind Regards, Scott On 2/27/12 2:25 PM, "ext Teco Boot" <[email protected]> wrote: >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
