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)
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)
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?: NEW 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. END
(Pete Resnick) Yes
(Ron Bonica) No Objection
(Gonzalo Camarillo) No Objection
(Benoit Claise) (was Discuss) No Objection
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)
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 WSDB - 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 prescriptive. - 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 requirement? - 5.3, O.3, that MUST is also odd as a protocol requirement - 5.3, O.4, see above comment about "current location"o - 5.3, O.5 seems to already have been stated, what's new here? - 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)
I support Martin's DISCUSS points.
(Russ Housley) No Objection
(Ted Lemon) (was Discuss) No Objection
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)
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)
Thank you for addressing my DISCUSS.