I am re-sending this email, as I got no feedback on my questions in it. The responses to the questions below would significantly influence the solution design, so I'd like to hear some feedback. Is there anybody who cares about it?
- Gabor From: [email protected] [mailto:[email protected]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley) Sent: Tuesday, December 04, 2012 11:57 AM To: [email protected] Subject: [paws] outcome of the Atlanta F2F -2- One main discussion point in the f2f was future extensibility, for the cases when regulators decide to require additional parameters from master devices; another discussion point was what parameters would the master initially, eg after the first power up, send to the DB. The suggestion was to extend the INIT procedure from a one round trip to a two round trips, where the first request from master would either be responded as already described in the draft, or the DB would respond with a message indicating additional required parameters, after which the master would resend the request with the indicated parameters. I believe this functionality could be supported by the currently defined one round trip INIT procedure as well, once the error handling is added to the document: 1. Master sends INIT request to the server, including at least its location 2. DB would respond with an error message, indicating the missing parameters 3. Master sends a new INIT request, including all the required parameters 4. DB sends to master the regulatory domain, parameter values and required behavior from master in this regulatory domain Am I missing sg? There was also another suggestion on having the parameters which could be carried in message 2 above be defined and put in the IANA registry. That way, the DB can easily point the master to which parameter it requires from it, possibly avoiding the need for a firmware update in the master (but still having the need for an admin to configure the required new parameter). And with the parameters in the registry, there would be no need to do per regulatory domain profiling of the required parameters. I would like to confirm if this path forward is ok with folks; if you have objections, then now is the time to speak up. What I believe we have not discussed, is the profiling or parameterization of the behavior required from master device in that regulatory domain (which would be sent from DB to master in either message 2 or 4 above). Ie, is it ok if the DB tells the master, that eg, the rules as defined in 'Ofcom-2012' or 'FCC-2013' are applicable (profiling), or should the behavior required by the rules be broken down into parameters and parameters defined in the registry (parameterization)? Profiling means that the master can only operate in one particular regulatory domain, if it is preconfigured with the profile applicable to that regulatory domain; Parameterization means that we have to identify the exhaustive list of parameters which describe the behaviours; which is a bit more work than the profiling. Any opinions on this? Thanks, Gabor
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
