Protocol to Access White-Space (PAWS) Databases
draft-ietf-paws-protocol-20

Stephen asked a geolocation question about RFC 6953 as it was being
processed to try to establish whether the location information supplied
for a query needed to be the location of the querrier or the location
about which the querry is being made. Going back to the text in 1.2 of
6953, it is pretty clear that the intent is to issue a queery that
relates to the whitespace at a location.

Given this, I agree with Stephen that including location info in the
INIT_REQ and REGISTRATION_REQ seems unnecessary. It seems to be being
used as some form of authorisation check, and I don't see how that is
safe or valid. But also I don't see what stops the sender from lying.
Surely the important thing is about where the whitespace is available,
not from where the requester operates?

But even in 4.5.1 there is some confusion...

   location:  The GeoLocation (Section 5.1) for the device requesting
      available spectrum.  The location SHOULD be the current location
      of the device, but more precisely, the location of the radiation
      center of the device's antenna.  When the request is made by the
      Master Device on its own behalf, the location is that of the
      Master Device and it is REQUIRED.  When the request is made by the
      Master Device on behalf of a Slave Device, the location is that of
      the Slave Device and it is OPTIONAL (see also
      masterDeviceLocation).  The location may be an anticipated
      position of the device to support mobile devices, but its use
      depends on the ruleset.  If the location specifies a region,
      rather than a point, the Database MAY return an error with the
      UNIMPLEMENTED (Table 1) code, if it does not implement query by
      region.

I don't see why you have SHOULD given the subsequent lowercase may.
Surely you need "the location it the location about which the enquiry
is being made."

Reading all this and going back to 6953 I am not sure I understand the
difference between having permission to operate on a frequency at a 
location (which seems to be granted by registration) and discovering
which frequencies are available (which seems to be determined by
AVAIL_SPECTRUM_RESP).

Clearly I am missing something in my read through. If you think it is
already covered, that's fine. But if not, perhaps you could add some
text to explain things.

I support Alissa's discuss - clarifying what is in the location, privacy around why point is required, and other privacy concerns.

Also - I note the 3 IPR claims for a, sorry, not particularly innovate (to my eyes) protocol - where the terms are RAND with reciprocity and RAND with possible royalty.  Those look like they'd kill any open source implementation?

Thanks for all your work to address my DISCUSS!

= Shepherd write-up=
"An in-depth review by a JSON expert might be useful." 

Did that happen?

= Section 1 =
"It opens the door for innovations in spectrum
   management that can incorporate a variety of parameters, including
   user location and time.  In the future, it also can include other
   parameters, such as user priority, time, signal type and power,
   spectrum supply and demand, payment or micro-auction bidding, and
   more."

Time seems to be listed both as a current parameter and a future one, which is confusing.

= Section 4.4 =
"FCC rules, for example, require that a 'Fixed Device'
   register its owner and operator contact information, its device
   identifier, its location, and its antenna height."
   
It would be nice to have a citation for the rules referenced here.

= Section 5.1 =
Feel free to ignore this if it's completely misguided, but does altitude really not matter? Are we sure this protocol won't be re-used for devices on airplanes trying to find available spectrum? (I note that in RFC 6953, requirement D.1 specifies that the data model must support "the height and its uncertainty" -- I have no idea what "the height" means or if it is related to altitude.)

= Section 10 =
I agree with Stephen that the database operator should be considered as a potential adversary from the standpoint of potentially being able to create a fine-grained database that tracks the locations and spectrum use patterns of individual devices. That data could certainly be abused.

Thanks for the updates!

"""
   [RFC Editor: In the Author's Addresses section, please list
   "iconectiv" as "iconectiv (formerly Telcordia Interconnection
   Solutions).  One occurrence."]
"""
Just make the edit yourself?


The document uses the terms "primary user" and "secondary user".  It would be helpful to define them.

"... the Master Device may verify with the Database that the Slave Device is valid"
How is "valid" being used here?

It seems a little constraining to describe this as a protocol between the Master Device and the database.  Might this protocol also be used between a Slave Device and a Master Device?

Section 5.1 seems to imply that a Geolocation object MUST NOT include both "point" and "region" components.  Is that case?  If so, that seems unfortunate; since region support is optional, it seems like it would be helpful for a client to be able to include a point as a fall-back.

Thanks for sorting out my discuss points.

I didn't fully check the location stuff is now all ok, but I
expect that since others had related discuss points 
it'll be checked more thoroughly (and it looks ok to
me too)

S.


--- old comments below, didn't check if they were handled or
not, but feel free to keep chatting about 'em if that's useful

- write-up: its a pity that coders haven't gotten together more
openly and done interop, but I guess different businesses are
different. 

- section 1, last para: I realise authorized devices is what
the WG are interested in, but the protocol ought not require
that, so the last sentence here is wrong - it surely should
be: s/device is authorized to operate/device operates/

- Ruleset: I hope there's a NULL, meaning "no rules":-)

- 4.4.1 - nothing stops a device lying about location, right?

- 4.5 - the slave location vs. master location seems unclear
to me. Can you clarify?

- 4.5.1 - timestamp has to be UTC right? You only seem to
indicate that via the "Z" in the timestamp format which I
expect could be easily missed. Suggest you emphasise that. You
should probably also say if truncated timestamps are ok, for
example just to the minute granularity without specifying
seconds.  I assume that's not allowed? And lastly, please
specify if the start (resp. end) of the second (or whatever)
unit is when a device gains (resp. looses) spectrum. (Or add a
global statement on timezones where you earlier said that
identifiers are case sensitive by default.) Some of this is in
5.14, but I'm not sure if that's enough. (It could be.)

- 5.2 - I don't get why you need X.520 here.

- 5.5 - could a vCard value just be (the moral equivalent of)
"Internet" or "I'm not telling"?

- section 7: Saying the master device MUST implement server
auth is confusing, since the master device is the TLS client,
right?

- Section 10: Under the privacy bullet you should also
recognise that an authorized entity can be privacy invasive
(e.g. selling contact information, sending all on to law
enforcement without permission).

- Section 10: Given diginotar and similar (incl. by nation
states), having the master device send its identifying
information in its first message means that simply saying "use
TLS" is not enough. You need to say "TLS, assuming the PKI
used is ok,..." or similar.

All the points in the discuss and comment have been addressed.   I am leaving them here for reference.

Section 3 describes spectrum-usage messages as purely informational.   Section 4.5 says that the database can require that such messages be sent.   Which is it: is it sometimes required, or always purely informational?   Or does "purely informational" just mean that the protocol provides no mechanism for tracking such notifications?  It would be helpful if this were clearer.

In 4.1, the database URI change spec seems incomplete.   Is there a time when a database starts announcing its URI change after which it need no longer provide service on the old URI?   I see Alissa asked a similar question, so I imagine you could address both questions together.

In 4.1 and 5.17, the meaning described for UNSUPPORTED appears to be somewhat fluid.   I think you intend for it to mean one specific thing, which might imply one of several other things.   But you don't say the one thing that it means: instead you mention possible implications.   It would be helpful to try to make this more explicit.

I think Stephen noticed this same problem, but to be clear, it appears that section 4.5 says that when the master is sending a request on behalf of a slave, it sends its own location.   But section 4.5.1 says that the master sends the slave's location.   It appears that there are two parameters, one being the master location, which is required, and the other being the slave location, which is optional.   However, this is never really stated explicitly; it might be helpful if it were.

I have to confess that the use of "master" and "slave" throughout this document makes me quite uncomfortable in reading it.   It would really be preferable to use terms that have less painful history associated with them, like "core" and "leaf" or "coordinator" and "supplicant."   I realize this is a matter of taste, and I do not at all mean to suggest that there's anything wrong with the use of these terms, which are certainly common in the computing industry.   This is just a comment, and whether you address it is entirely up to you.

In 4.6.1, it would help to have text that explains what it means to validate a device.   It's certainly not required for interoperability, but might be helpful for implementors of database servers.

In 5.3, it's a little puzzling that antenna direction, radiation pattern, gain and polarization aren't defined, because they seem like properties that should have universal applicability, even if they are not required in all cases.   Is this being left as future work, or is there some more subtle reason why these haven't been defined explicitly?

In 5.11, power is expressed in dbm, which leads me to wonder if this is the product of the antenna gain and the input power to the output amplifier, or whether it's just the input power to the amplifier, or whether it's being left intentionally ambiguous.

Former DISCUSS points:

This is a cool document—I'm glad the IETF is working on this.   Please don't take the following comments as anything other than an attempt to address what I think are some relatively minor issues with the document, hopefully easily addressed.

4.1 says "Some regulatory domains may have specific rules regarding how long the spectrum data remains valid in these cases."   It might be worth adding that in such cases the initialization procedure is required.   This is addressed to some extent in section 4.3, but I'm not sure it's completely addressed.   The potential problem I see is that a device might be used in a regulatory regime where this is required, but might have pre-configured values for some other regulatory regime.   If these values are not valid in the regime that applies for its current location, it might have a too-long refresh interval configured, fail to detect that this is the case, and as a result accidentally break the law.   Can a scenario like this occur in practice?

Section 5.2 says that the manufacturer ID and model ID are optional, but may be required by some rulesets.   Section 4.3.1 does not say what error is returned when a deviceDesc that does not contain one or both of these parameters is sent to the server, but the matching ruleset requires either parameter.   I suspect the answer is straightforward, but I think it needs to be stated explicitly in 4.3.1.   E.g., if the optional but required parameters are accepted in the initialization but rejected in the registration, it would be good to say so explicitly.

In 4.4.2, I think that if none of the rulesets are accepted, the intent is that the database should return a REGISTRATION_RESP with the error element, and will not return a rulesetInfos list.   However, the specification does not make an exception for this case when it says "A RulesetInfo list MUST be included" and  "The list MUST contain at least one entry".   I can't think of another valid interpretation, but you've stated a MUST, so you need to say that it doesn't apply in the case of the error.

In 4.5:

       If some
       locations within a batch request are outside the regulatory
       domain supported by the Database, the Database MAY return an OK
       response with available spectrum for only the valid locations;
       otherwise, if all locations within a batch request are outside
       the regulatory domain, the Database MUST respond with an
       OUTSIDE_COVERAGE error.

What should the database do if it doesn't follow the MAY?   Should it return an OUTSIDE_COVERAGE error?   It seems to me that this MAY is going to require some unclear heuristics on the side of the master device.   Why isn't this a MUST?   I think if this were a MUST, it would be clear how implementations should behave; by making it a MAY, there's a big gap that I think will lead to interoperability problems as different implementors make different choices about how to treat this situation.