I would be in favor of anything that could make such things extensible without having to re write…maybe some of the DB guys can weigh in on this as well.
Sincerely, Nancy On Jan 9, 2013, at 6:54 AM, <[email protected]> wrote: > 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
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
