Dear all I would support the view that there be provision for including information that the dB would 'like' to know, or more to the point could 'usefully' know, in order to optionally provide more value-added services. Examples might be to pre-clear spectrum when a WSD is moving, or to take account of antenna directivity.
Best wishes Michael Fitch, BT -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Warren Kumari Sent: 08 January 2013 23:17 To: [email protected] Cc: [email protected] Subject: Re: [paws] outcome of the Atlanta F2F -2- 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". 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? > > 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... 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 _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
