[paws] Alissa Cooper's Discuss on draft-ietf-paws-protocol-14: (with DISCUSS and COMMENT)

["Alissa Cooper" <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-paws-protocol-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm glad this work is being done in the IETF, thanks for all your
effort.

A couple of my points below have overlaps with some of Stephen's points.

= Shepherd write-up = 
"Yes, there were 2 IPR disclosures filed that reference this document.
They were discussed in the WG, and nobody came forward to say that they'd
like to change anything in the document because of the disclosures."

But there are 3 IPR disclosures in the tracker, not 2. Were all three
discussed in the WG?

= Section 4.1 =
"A Database MAY change its URI, but before it changes its URI, it MUST
   indicate so by including the URI of one or more alternate databases
   using DbUpdateSpec (Section 5.7) in its responses to devices."

The behavior here seems ambiguous. Does the database need to send
responses containing the updated URI to all devices it has ever
communicated with, or all registered devices, before it can actually
change the URI? Does the database even maintain such lists? If not, how
many such responses does it need to send out before changing its URI, or
how long does it need to wait? Just saying that sending the new URI needs
to happen "before" the URI changes does not seem specific enough for
devices to know whether the URI has changed, or for databases to know
when they can disable an old URI or stop sending the DbUpdateSpec
indication.

= Section 4.5 =
These two sentences seem to contradict each other:

"The device identifier, capabilities, and characteristics
   communicated in the AVAIL_SPECTRUM_REQ message MUST be those of the
   Slave Device, but the location MUST be that of the Master Device."

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

Perhaps this can be solved by making the reference to "the location" in
the first sentence more specific -- the masterDeviceLocation -- but I'm
not really sure from reading the text.

Then later in the section, I started getting even more confused by this:

"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).
      ...
masterDeviceLocation:  When the request is made by the Master Device
      on behalf of a Slave Device, the Master Device MAY provide its own
      GeoLocation (Section 5.1)."

Does this mean it's acceptable for a Master device acting on behalf of a
Slave device to send neither the Slave device location (in the location
parameter) nor the Master device location (in the masterDeviceLocation
parameter)? I believe that the current text allows this. If so, why is
location required in the registration step (and in batch available
spectrum requests) but not in the available spectrum step? Seems like it
should be the other way around -- that a device could register without
specifying its location, but not request available spectrum without it. 

If the above interpretation was not intended, something needs to be fixed
in one part or the other of the above text to indicate that either the
Master device location or the Slave device location (or both) must be
present in the request.

The same issue arises in Section 4.5.5.

= Section 5.1 =
I'd like to discuss why the single point location format needs to be
supported here. Is it really the case that a portion of whitespace
spectrum will ever be available only at a single point, as opposed to a
region? If not, it seems like sending a point (and, moreover, allowing
region to be unsupported but not point) divulges more precise information
about the requesting device than is ever actually necessary to fulfill
the goals of this protocol. Do regulators require a single point? Why?

= Section 5.2 =
I'd like to discuss why the device serial number needs to be included in
the device descriptor, rather than some (perhaps persistent) randomly
generated device identifier that is used only in the context of this
protocol (which would better protect the privacy of the user of the
device, since the whitespaces database administrator wouldn't be able to
correlate the device's spectrum requests with other activities linked to
the serial number). It's not really clear why serial number is collected
since both this document and RFC 6953 note the protocol does not defend
against abuse or mis-use of spectrum.

I'm asking the above two questions in light of requirement P.7 from RFC
6953, "The PAWS protocol SHOULD support privacy-sensitive handling of
device-provided data where such protection is feasible, allowed, and
desired."

A separate interesting question that does not seem to be addressed
anywhere in the draft is whether a device can be fingerprinted by the
database operator by virtue of the collection of elements it sends
(rulesetIds, manufacturer, model, antenna characteristics, device
capabilities, etc.) even if it doesn't send a serial number or device
owner information that uniquely identify it. That seems worth discussion
in Section 10.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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