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