On Jan 9, 2013, at 2:28 AM, Vincent Chen <[email protected]> wrote: > > > > On Tue, Jan 8, 2013 at 3:16 PM, Warren Kumari <[email protected]> wrote: > > On Jan 8, 2013, at 5:02 PM, [email protected] wrote: > > > I am re-sending this email, as I got no feedback on my questions in it. > > Apologies. This got lost in a mailbox... > > > 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? > > I don't care deeply, but have *some* opinions... > > > > > - 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? > > Only some clarifications: > I thing that 2 is actually: If the Master included all parameters that the DB > needed, things proceed normally. If there are parameters that the DB needs, > then "DB would respond with an error message, indicating the missing > parameters". > > Agreed. > > > Also, if the DB requests that the Master send Color_of_Unicorn and the Master > doesn't know this, what happens? What if this is simply something the DB > would *like* to know, but is OK proceeding without it? > > I think it the DB is OK proceeding without it, then it is not a "required" > parameter, so it should just proceed to return the requested information. > If it must know, and the Master doesn't know it, then the DB must still > respond with an error. > I don't think there is an inconsistency. > > > > > > > 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. > > Yup. This sounds good -- I don't really think that avoiding firmware updates > are likely, but a registry would defiantly make it easier to track allocation > of code points, etc. Much simpler to instruct the IANA to assign something in > a registry (possibly after RFC or stable reference) than to keep obsoleting > docs, following long chains of drafts, etc... > > > > > > 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. > > No objections... > > > > > 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? > > Yes… Parameterization is (IMO, etc) much much simpler. > > Let's say that Ofcom-2012 requires "rules" A, B, C and J and that FCC-2013 > requires A, J, X, Y and Z. > I have made a widget that works in both FCC and Ofcom worlds, so I know about > rules A - Z. > > In the future Ofcom decides that they also want to require / support rules X > and Y, so they make a new profile called "Ofcom-2020", which requires A, B, > C, J, X, Y. > > If we use profiles, until I roll upgrade all of my devices I won't know what > all is required in the Ofcom-2020 profile, *even though* I know about all of > the "rules" / parameters. If instead the DB simply says "Please send me A, B, > C, J, X, Y" I'm golden… > > Actually, there are two halves to this. > > What you're contrasting is a profile name versus a set of configuration > parameters for the device. Here, I would agree that just having configuration > parameters is more flexible/extensible. > > The other half of the problem is that the DB needs to know that the device > will know what to do with the answers it returns. > > Suppose a device has been certified for FCC-2013, but FCC-2015 adds some > additional device requirements where, if satisfied, would allow enhanced > spectrum usage: > - Device contacts DB telling it is compliant with FCC-2013 > - DB will not ask the device for new required parameters under FCC-2015 rules > - DB responds with "degraded" spectrum compliant with FCC-2013 rules
What about: - Device contacts DB telling it that it understands requirements [A, B, C, P, Q, J] - DB will not ask the device for new required parameters under FCC-2015 rules (which added requirement X, Y and Z) - DB responds with "degraded" spectrum compliant with FCC-2013 rules This way only the DB needs to know about profiles. If I make a white space compatible hairbrush I really don't want to have to know about all of the different countries required profiles, and don't want to have to roll new profile sets every time a regulator adds a new requirement to their set. If the requirements / parameters are something like a menu in a restaurant then regulators can pick and choose (and change) their requirements as they see fit… > > (Assuming regulator allows both types of devices to continue to operate) > > These named rulesets may also allow new regulators to simply adopt an > existing ruleset. E.g., Regulator B will allow FCC-2015 devices. Well, kinda. If Regulator B wants to support FCC-2015 except that they don't want Subsection 3, Clause 12.2.8.3 they are kinda stuck. Or, if they want a superset of FCC-2015 and Ofcom-2013 or… Simply doing a capability exchange with available (numbered or names) parameters allows regulators to build *their* preferred profile without device manufacturers to know about it. FCC and Ofcom and Telkom and and and can still publish "profiles" somewhere (maybe in the same IANA registry), but the profile would look more like: FCC-2013: Required [ A, B, C, J] Optional [ P, Q] FCC-2015: Required [ A, B, C, J, P] Optional [Q, X, Y, Z] Ofcom-2013: Required [ A, B, C, J ] Optional [ P, R, X, Y ] Telkom-1886: Required [ A ] Building and transmitting a list of supported parameters is easy, tracking every regulators set of requirements in their profiles is "hard" :-P W > > -vince > > > W > > > > > > Thanks, Gabor > > _______________________________________________ > > paws mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/paws > > -- > It is impossible to sharpen a pencil with a blunt axe. It is equally vain > to try to do it with ten blunt axes instead. > -- E.W Dijkstra, 1930-2002 > > > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > > -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
