Guilty of not reading the doc carefully enough. Why yes it does. Brian
On Feb 27, 2012, at 5:08 PM, <[email protected]> wrote: > Hi Brian, > > I agree we should be flexible enough to send device information with the > spectrum query when requested by the local regulator. Does P.12 address > this accurately? > > Kind Regards, > Scott > > > > On 2/27/12 3:38 PM, "ext Rosen, Brian" <[email protected]> wrote: > >> <as individual> >> I have a small issue here. >> >> Device characteristics don't typically change, so having them in some >> form of registration transaction makes sense in an engineering sense. >> However, some regulators don't seem to understand that, and there are >> circumstances where you have to send some of the device information with >> the spectrum query. We should be flexible enough to handle that. >> >> Brian >> >> On Feb 27, 2012, at 3:46 PM, <[email protected]> >> <[email protected]> wrote: >> >>> 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 >> > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
