Protocol to Access White-Space (PAWS) Databases: Use Cases and Requirements
draft-ietf-paws-problem-stmt-usecases-rqmts-15

Thanks for addressing my DISCUSS/COMMENT

I support Martin's DISCUSS points.

Thank you for addressing my DISCUSS.

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?

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.

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.