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 (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. -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 >
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
