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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 20 Aug 2014 09:52:36 -0700

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.

---

From: Russ Housley <[email-masked]>
Date: Wed, 20 Aug 2014 15:31:17 -0400

I would like to see Sections 9.1 say something more about the ruleset specification.  In particular, I wonder if it is possible to say anything about stability, availability, or free access.

Russ

---

From: Pete Resnick <[email-masked]>
Date: Wed, 20 Aug 2014 23:04:27 -0500

Wow! We never received notification of that 3rd IPR disclosure and I 
therefore totally missed it. The fact is that it appears to be on the 
as-yet-undefined and perhaps never-to-be-finished discovery part of the 
protocol, so the WG may not care. But the WG must be consulted. Good 
catch! Don't know how I missed it in my final check.

(I'll independently check with the secretariat about how we missed the 
announcement.)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 00:59:00 -0700

Alissa,

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

> http://datatracker.ietf.org/doc/draft-ietf-paws-protocol/

Pete addressed this.

> when they can disable an old URI or stop sending the DbUpdateSpec

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.

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

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

> The same issue arises in Section 4.5.5.

Yes. Will fix.

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

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

> owner information that uniquely identify it. That seems worth discussion

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

Tim Bray had looked at it before final call.

> Time seems to be listed both as a current parameter and a future one,

Agreed. The second "time" should be removed.

> It would be nice to have a citation for the rules referenced here.

OK.

> and its uncertainty" -- I have no idea what "the height" means or if it

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.

> 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

---

From: Pete Resnick <[email-masked]>
Date: Thu, 21 Aug 2014 10:04:24 -0500

> Ouch! I'll fix that. "... location MUST be that of the Slave Device."

Do we have any idea how that got in there in the first place? That seems 
like it was a conscious decision, and I want to make sure we're not 
missing something.

pr

---

From: Pete Resnick <[email-masked]>
Date: Thu, 21 Aug 2014 10:59:36 -0500

On 8/21/14 2:59 AM, Vincent Chen wrote:
> determines that a series was defective. The Databases must use the 
> serial number

But that makes this a "required by ruleset but not by protocol" issue, 
right?

pr

---

From: Vincent Chen <[email-masked]>
Date: Thu, 21 Aug 2014 09:39:33 -0700

On Thu, Aug 21, 2014 at 8:04 AM, Pete Resnick <[email-masked]>
wrote:

> like it was a conscious decision, and I want to make sure we're not missing
> something.
>

Yes. In response to last call on draft 7 back on 2013-12-03, Sajeev
Manikkoth suggested that we should have the ability to include the Slave
location.
In response, I proposed adding a masterDeviceLocation to refer to the
Master's location, but I screwed up the text.

>
> pr
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

-- 
-vince

---

From: Gabor Bajko <[email-masked]>
Date: Thu, 21 Aug 2014 16:32:02 -0700

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

> This  3rd IPR disclosure seems to have surfaced 2 months after the
shepherd write-up, that is why it is not mentioned in the write-up.
I think the best we can do now is to consult the WG about this disclosure
in parallel with the iesg evaluations.
Gabor

---

From: Vincent Chen <[email-masked]>
Date: Fri, 22 Aug 2014 13:28:40 -0700

> But that makes this a "required by ruleset but not by protocol" issue,

I think this comes back to the question you asked during the drafting of
RFC 6953:

>> Are there any potential implementers of this protocol (or potential
regulatory bodies) that *don't* care about [serial number], manufacturer or
model or etc.?

There were no solid answers to that question. I suppose the most flexible
is to make it optional at the
protocol layer and required by ruleset, as you suggest.

-- 
-vince