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

[Vincent Chen <[e-mail]>]

Alissa,

Thanks and sorry for the delay. Please see answers inline.


On Wed, Aug 20, 2014 at 9:52 AM, Alissa Cooper <[e-mail]> wrote:

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

Pete addressed this.


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

Thanks for pointing this out. Note that this is not a push mechanism, so
there
is no list of clients to maintain. Rather, the DbUpdateSpec is added
to the responses when a Device contacts the Database.

Propose adding the following clarifying points to add to the text:
  - The database SHOULD reply with DbUpdateSpec for a minimum of 2 weeks
before disabling the old URI.


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

Ouch! I'll fix that. "... location MUST be that of the Slave 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)."
>

You're right to be confused. Sorry. masterDeviceLocation is required when
the
Master Device is making a request on behalf of a Slave Device.
Needs to be fixed for BATCH request also (4.5.3 and 4.5.5)


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

Yes. Will fix.

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

The resulting spectrum is valid for 100m (typically) radius around that
point.

Computation of available spectrum for a region is actually complex and not
well defined...


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

The regulator want to have the ability to black list ranges of serial
numbers, if it
determines that a series was defective. The Databases must use the serial
number
to determine it can return available 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.
>

What should the discussion say? Just that it is possible? or does it need
to have a solution?


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> = Shepherd write-up=
> "An in-depth review by a JSON expert might be useful."
>
> Did that happen?
>

Tim Bray had looked at it before final call.


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

Agreed. The second "time" should be removed.


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

OK.


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

See Section 5.3 on "height" of the antenna. It's separated out, from the
"latitude, longitude" specification
of GeoLocation. It allows specification with respect to ground level or
mean sea level, and is intended
for Fixed devices, rather than mobile devices.

>From the current regulator's perspective, the allowed power for mobile
devices is low enough that
height does not matter.



>
> = 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.
>
>
So just listing that as a potential threat and declare that fixing this as
out of scope is sufficient?

Or do we need to state that Databases MUST not track? I can see how
anonymized tracking
can be useful for spectrum management in the future, much like anonymized
tracking of car locations
provide valuable traffic information for navigation systems.

-- 
-vince