Hi Scott, Op 27 feb. 2012, om 21:46 heeft <[email protected]> <[email protected]> het volgende geschreven:
> 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? Yes, this is fine. And remove P.10? Thanks, Teco > > 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
