Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements

Note: This ballot was opened for revision 13 and is now closed.

(Stewart Bryant) Yes

Comment (2013-02-19 for -13)
No email
send info
This is a well written document.


As a purely historical note (with no action required) primary-secondary is actually a much older concept than the draft appears to describe. However, pre-computer the cognitive element was provided by a human operator who was expected to avoid the primary by listening for them prior to transmitting, and to act on a QSY request, possibly sent in morse by the primary. 


"A preferred option is to make use of a robust protocol that has been adopted and implemented by radio
manufacturers.  " could usefully have a reference.


The draft says:

"It is assumed that an attacker has full access to the network medium between the master device and the white-space database. "

and yet does not discuss a jamming attack. It is fine for this to be out of scope, but it is a valid threat in some scenarios.

(Wesley Eddy) Yes

Barry Leiba Yes

Comment (2013-02-15 for -13)
No email
send info
There were extensive changes in version -13 after last-call comments (including mine), and they have resolved all of my concerns.  I'm happy to put a "Yes" on this version.

There's a minor non-blocking item introduced by a new paragraph in the Introduction:

-- Section 1.2.1 --

   Note.  The above protocol actions should explicitly or implicitly
   support the ability of devices to re-register and/or re-query the
   database when it changes it location or operating parameters, to
   receive permission to operate in its new location and/or with its new
   operating parameters, and send an acknowledgment to the database that
   includes information on its new operating parameters.

This is new with -13, and is unclear as to the antecedent of the "it"s -- you appear to be talking about the database, when you're really talking about the devices.  Maybe this, taking advantage of the plural "devices" that you already have?:

   Note.  The above protocol actions should explicitly or implicitly
   support the ability of devices to re-register and/or re-query the
   database when they change their locations or operating parameters.
   That will allow them to receive permission to operate in their new
   locations and/or with their new operating parameters, and to send
   acknowledgments to the database that include information on their
   new operating parameters.

(Pete Resnick) Yes

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2013-03-15)
No email
send info
Thanks for addressing my DISCUSS/COMMENT

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-03-04 for -14)
No email
send info
Thanks for handling my discuss points. (I didn't check the
non-blocking comments below so they may have been 
handled or not. Feel free to chat more about them if 
you want.)

- 1.2.1, 1st para: I think "database" is wrong here and
you'd be better to say service, e.g. the point 1 below
says WSDB and that makes two uses of database which could
be confusing.

- 1.2.1, point 3: Does this assume that the geolocation
is that of the querying device at the moment of the
query? Why can't I ask in advance from another device,
knowing that I'm about to move to a location or install a
temporary device tomorrow? If the PAWS protocol does not
support the above or justify why its out of scope ,
that'll likely be a DISCUSS level issue for me I think,
but its just a comment here. I think I'd also like the
protocol to allow me to ask about the past as well. Note
that I do not mean that every WSDB has to provide the
answers to such queries, but the protocol should allow
for that to happen if the device and WSDB and regulators
etc all think that its useful.

- 1.2.2, just a query - why is interference avoidance out
of scope entirely? I agree that detection and prevention
of interference is not something that the PAWS protocol
should try to guarantee, but it could provide useful info
that would help.

- 1.2.2, you might think it silly, but I could see the
same protocol being used for other things, so maybe you
want to say that you're only dealing with RF spectrum
here? Example other medium: underwater acoustic
networking, DB might tell me where and when to find a n/w
under the sea. But feel free to ignore this comment:-)

- section 3, I'd say s/should be relulatory
independent/must be independent of any particular
regulatory environment/

- 3.2, 1st para, do you really mean the address of the

- 3.2, Why must I trust the WSDB directly? If the data I
get via the PAWS protocol were digitally signed then I
would be trusting the signer and the WSDB might be less
(or differently) trusted. Again, that's ok here, but
might result in DISCUSS level issues with the PAWS
protocol but those can be worked out later.

- 3.2, Is this set of steps given here supposed to rule
out possible uses of DNS for service location? If so,
then I think you need to justify that (perhaps premature)
design choice here. I'm going to assume that DNS might be
considered by the WG as one method for doing this. (Note:
I'm not saying I think the WG should use DNS, but that
the WG should think about use of DNS.)

- section 3 generally: it might help to say that this is
just generally descriptive text and not meant to be

- 4.1, step 7 has the master tell the WSDB about the
slave identity (perhaps). That has privacy and security
concernts that I hope are covered later.

- 5.1 has 2119 keywords, but 5.1, P.1 doesn't. What's up?

- 5.2, P.1 saying "URI address" seems likely to tee up an
argument, why not just a URI?

- 5.2, P.15 "timely manner" seems vague and liable to
generate discussion later.

- 5.3, O.2 seems odd - how is that a protocol

- 5.3, O.3, that MUST is also odd as a protocol

- 5.3, O.4, see above comment about "current location"o

- 5.3, O.5 seems to already have been stated, what's new

- section 7: I don't get why there's no threats related
to slave devices, nor for a device spoofing as a master
to a WSDB. 

- 9.2, I think there must be better references for this.

(Brian Haberman) No Objection

Comment (2013-02-18 for -13)
No email
send info
I support Martin's DISCUSS points.

(Russ Housley) No Objection

(Ted Lemon) (was Discuss) No Objection

Comment (2013-03-19)
No email
send info
In 4.1

Common steps may occur in master-slave networks include the following:        

should probably be something like:
Common steps that may occur in master-slave networks include the following:

In 4.3 

  Once the bridged device (WS + Wi-Fi) is connected to a master and WS            
  network, a simplified operation scenario of backhaul for Wi-Fi                  
  consists of the following steps:
This text doesn't use the name used in Figure 4 for the WS+WiFi device, which is          
"Slave Bridge to WiFi."  I was able to connect the dots, but it could           
be made clearer.

I don't consider either of these observations to be a big deal, just thought I'd mention them since they popped out at me as I read the document.

Changing this from DISCUSS to COMMENT based on jabber conversation with Pete:

The document mentions revoke messages, but of course these only work if the WSD is still reachable.  The document doesn't talk about what happens if a WSD becomes unreachable after it's received a whitespace configuration.  Do whitespace configurations always have lifetimes, so that if a WSD runs out of power, for example, the database doesn't keep its allocation around forever?

This is probably obvious to readers who are in this space, but as a neophyte it wasn't obvious to me.   I suspect it's worth fixing, but am willing to be convinced otherwise.

(Robert Sparks) No Objection

Comment (2013-02-18 for -13)
No email
send info
Why is the information in D.9 limited to frequencies and power-level? Are other characteristics of the use of the spectrum (operating mode and the bandwidth consumption that comes with them) implied by something else? Or should such data be called out here?

(Martin Stiemerling) (was Discuss) No Objection

Comment (2013-03-05 for -14)
No email
send info
Thank you for addressing my DISCUSS.