Subject: Re: [paws] outcome of the Atlanta F2F -2-

From: <[email-masked]>
Date: Tue, 8 Jan 2013 22:02:32 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Bajko Gabor (Nokia-CIC/SiliconValley)
Sent: Tuesday, December 04, 2012 11:57 AM
To: [email-masked]
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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Jan 2013 18:16:48 -0500

> 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...

> 4.       DB sends to master the regulatory domain, parameter values and required behavior from master in this regulatory domain

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 p…

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)?

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-masked]
> 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

---

From: Vincent Chen <[email-masked]>
Date: Tue, 8 Jan 2013 23:28:28 -0800

On Tue, Jan 8, 2013 at 3:16 PM, Warren Kumari <[email-masked]> wrote:

> > 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?
>
> > 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:
> > 4.       DB sends to master the regulatory domain, parameter values and
> required behavior from master in this regulatory domain
> >
> > Am I missing sg?
>
> 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?
>
> 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

---

From: <[email-masked]>
Date: Wed, 9 Jan 2013 14:54:59 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Warren Kumari
Sent: 08 January 2013 23:17
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] outcome of the Atlanta F2F -2-

No objections...

> 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. 

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

--
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

---

From: Nancy Bravin <[email-masked]>
Date: Wed, 9 Jan 2013 07:16:25 -0800

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 9 Jan 2013 10:23:08 -0500

On Jan 9, 2013, at 2:28 AM, Vincent Chen <[email-masked]> wrote:

> 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.
> 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:
>  - DB will not ask the device for new required parameters under FCC-2015 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…

> 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

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 9 Jan 2013 09:48:43 -0800

Gabor,

First, agree that extensibility is a must.  No regulatory agency will
get it all right the first time.

Extending Michael's thoughts a bit here:
	- DHCP implementations have sticky memories.  If you shut off your
office computer, then, after a weekend of carousing, turn it back on,
then if the IP address you used to have is still in the pool it will be
reassigned to you.  If the database were to have this kind of
stickiness, then a down-the-calendar request for spectrum might require
less startup information (over what might be a low-bandwidth
connection).
	- it might make sense for the db to award a minimal amount of spectrum
in order to get _a_ connection working.  Then the master could use that
connection as the means to amend its request.  Do we have to get
everything right in the first request?

---

From: Vincent Chen <[email-masked]>
Date: Wed, 9 Jan 2013 15:38:01 -0800

+paws

> > 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.
> >
> rules (which added requirement X, Y and Z)
> 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…
>
> >
> 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:
>
> Building and transmitting a list of supported parameters is easy, tracking
> every regulators set of requirements in their profiles is "hard" :-P
>
> W
>

Some more thoughts:

 1. It may be to the best interest of a regulator to adopt an existing rule
set, because all those devices would just work.
   If a regulator chooses to modify the rules, then it takes on the burden
of certifying that a device still works correctly, since:
  a. The device may never have operated in that particular configuration
before

  b. Or, conversely, it's a burden to have the device manufactures test the
device in all possible combinations of requirements, just in case some
regulator might want to use it in a particular configuration.

  c. There is no guarantee that a mix-and-match of requirements still
results in the right behavior. It might result in refactoring of
requirements, which will make this a really complex system to understand.

 2. Also, there are regulatory rules that involve only the device and is
not (and probably should not be) reflected in the protocol or Database.
(E.g., how a device must select channels and powers from the available
spectrum list provided by the Database). The assertion of which rule set
the device supports allows the Database to determine easily whether it can
service that device.

Are you confident that one can always decompose a set of regulations into a
set of orthogonal requirements allowing mix and match?

-- 
-vince