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

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]

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.

[Ballot discuss]
Can you please reply to Juergen Schoenwalder OPS directorate review. Non editorial comments are copied here for your convenience:

    Here is my OPS-DIR review of draft-ietf-paws-problem-stmt-usecases-rqmts-12.

    This is a problem statement and requirements document, not a protocol
    specification. Content wise, I am unclear how the protocol is going to
    deal with situations where the device's notion of a white space lease
    and the database's notion of a white space lease get out of sync. I
    would assume that any white space usage leases would be time bound,
    that is, they create soft state at master devices that needs to be
    periodically renewed.  However, the text does not seem to say this.
    Relying on the ability of the database to inform master devices of
    changes to spectrum availability (P.15) may be risky since devices may
    simply loose connectivity. In other words, I am not sure there has
    been enough thoughts to think about operational complications that can
    occur (such as loosing connectivity) and what that means to the
    operation of the white space database access protocol.

    I am also concerned about the privacy implications. While there is
    some discussion in the security considerations, I am in particular
    concerned that there might be regulators that are not so much
    interested in regulating white space usage but rather in tracking user
    information. As such, I think there really needs to be an
    implementation requirement that usage of white space databases and in
    particular the transmission of device owner information etc. is
    something that a user explicitely needs to agree to for a given
    regulatory domain. I would be scared if a portable device I am
    carrying would send a detailed trace of my movements to a database in
    arbitrary regions of the world I may visit.

    Editorial nits:

    - s/connection to the a WS connection/connection to a WS connection/

    - The requirements language blurb appears twice in the document, I
      think having this text once is really sufficient.

    - I find the references unusual. We usually follow traditional ways to
      reference RFCs and I-Ds. Also for pure URLs, it is common to note
      when the page was retrieved. In particular, wikipedia pages can
      change anytime. Please refer to I-Ds in the usual way.

    - I find the author information unusual - just last names, no
      affiliation, not even a first letter of the given name, as it seems
      common practice in RFCs. Earlier version of the I-D has more
      complete author information, including affiliation. I am wondering
      why all that has been removed (in fact, I first was not sure whether
      Mancuso is affiliated with an organization called Probasco so I
      scrolled to the Authors' Address section and found that apparently
      Probasco is a name of a person but all three authors seem to prefer
      to be somewhat anonymous - which is strange since full names are
      provided in the acknowledgments).


A mix of DISCUSS and clarifying questions. Hopefully, I'm missing something obvious and they will be quickly be solved.

- I'm missing the fact the database is updated with the used spectrum.
If the database is not updated, how do we keep data synchronization?
Is this what you mean by
  O.1  The database and the master device MUST be connected (e.g.,
      through the Internet).

- Clarifying question (for now)

In

  2.  Slave devices power up and associate with the master device via
      Wi-Fi or some other over-the-air non-white-space spectrum.  Until
      the slave device is allocated white-space spectrum, any master-
      slave or slave-slave communications occurs over such non-white-
      space spectrum.

Aren't you missing

  The slave device may register with the master device and/or the database
  before it queries the database for available spectrum.

- Clarifying question (for now)

  5.  The master sends a query to the trusted database requesting a
      list of available white-space spectrum based upon its
      geolocation.

How come that you only send the master geolocation and not the slave's one?
Is there a situation where we could have no interference at the master location, but well at the slave location?

-
  P.5  The messages sent by the master device to the database and the
      messages sent by the database to the master device MUST support
      integrity protection.

And not between the slave device and the master?

[Ballot comment]
- Juergen has got some editorial comments part of the OPS directorate review

- Editorial

Automation of the this allocation and assignment is
  often the best solution.

- Editorial

                -----------
                |  Master |
                |WS Device|                              ------------
                |Lat: X  |\          .---.    /--------|Database X|
                |Long: Y  | \        (    )  /        ------------
                -----------  \-------/      \/              o
                                    ( Internet)              o
                -----------  /------(        )\              o
                |  Master | /        (      ) \
                |WS Device|/          (_____)  \        ------------
                |Lat: X  |                      \--------|Database Y|
                |Long: Y  |                              ------------
                -----------
That confused me for a second that the Databases are called X/Y, similar to the Lat/Long.
Specifically because there is no explanatory text. So I guessed that Lat = Latitude and Long = Longitude

[Ballot comment]
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.

[Ballot discuss]

(1) I agree with Martin's discuss about privacy, but have
a suggestion. I think that could be handled via a generic
requirement on the protocol.  For example, maybe
something like the following "Tracking of master or slave
device uses of WS could be considered invasive of
privacy, including of privacy regulations in specific
environments. The PAWS protocol SHOULD be designed so as
to allow for privacy-friendly operation where that is
feasible, allowed and desired."

(2) As a particular instance of the above, 5.2/P.13 says
you "MUST include slave device ID" which does not appear
to be needed all the time everywhere, so ought not be
required? I think that s/MUST/MAY/ is what's needed here
or perhaps s/device ID/device information/ since in some
places just a device class/type might be enough.

(2) 5.3, O.6 - this seems broken to me since it precludes
a setup where the master does not have to tell the WSDB
about each slave. I think it probably also contradicts
earlier text, as well as being inefficient in some cases
and not allowing a privacy friendly mode of operation.

[Ballot comment]

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

[Ballot comment]
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?

[Ballot discuss]
I have no general objection to the publication of this draft but 2 issues to be discussed:

1)
Section 1., paragraph 0:

>    1.  The master device sends registration information to the database.
>        This information may include the Device ID, serial number
>        assigned by the manufacturer, device location, device antenna
>        height above ground, name of the individual or business that owns
>        the device, and the name, street and email address, and telephone
>        number of a contact person responsible for the device's
>        operation.

  I haven't seen any word about user privacy in the security
  conderations. This looks like a fault, as the above text suggest that
  potentially a lot of user sensitive data is send to the database.


2)
Section 5.3., paragraph 2:

>    O.1  The database and the master device MUST be connected (e.g.,
>      through the Internet).

  Given the other requirements, this requirement is extremely high
  level. Does this mean, for instance, that the master device and
  the db must be constantly connected to each other? And what does
  connected mean anyhow, e.g., have a working networking path in
  between or a TCP connection opened at all times?

[Ballot comment]
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

IANA has reviewed draft-ietf-paws-problem-stmt-usecases-rqmts-12,
which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Protocol to Access White Space (PAWS) Database: Use Cases and Requirements) to Informational RFC


The IESG has received a request from the Protocol to Access WS database
WG (paws) to consider the following document:
- 'Protocol to Access White Space (PAWS) Database: Use Cases and
  Requirements'
  as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-15. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Portions of the radio spectrum that are assigned to a particular use
  but are unused or unoccupied at specific locations and times are
  defined as "white space."  The concept of allowing additional
  transmissions (which may or may not be licensed) in white space is a
  technique to "unlock" existing spectrum for new use.  An obvious
  requirement is that these additional transmissions do not interfere
  with the assigned use of the spectrum.  One approach to using white
  space spectrum at a given time and location is to verify spectrum
  availability with a database that manages spectrum sharing and
  provides spectrum-availability information.  The IETF has undertaken
  to develop a Protocol to Access Spectrum Database [1] for such a
  management database.

  This document describes a number of possible use cases of white space
  spectrum and technology as well as a set of requirements for the
  database query protocol.  The concept of white spaces is described
  along with the problems that need to be addressed to enable white
  space spectrum for additional uses without causing interference to
  currently assigned use.  Use of white space is enabled by querying a
  database that stores information about spectrum availability at any
  given location and time.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1614/

As required by RFC 4858, current Document Shepherd Write-Up per
latest format at http://www.ietf.org/IESG/content/Doc-Writeup.html.

Document Shepherd Write-Up for draft-ietf-paws-problem-stmt-usecases-rqmts-08:

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

==> Informational, as indicated in the title page. The document describes potential use cases for TV White Space spectrum and summarizes the Requirements of the protocol a White Space device has to use to get access to the spectrum. Requirements were derived from the rules Regulators have adopted for White Space functionality.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
==> The document describes a number of possible use cases of white space
spectrum and technology as well as a set of requirements for the
database query protocol. The concept of TV white spaces is described
including the problems that need to be addressed to enable white
space spectrum for additional uses without causing interference to
currently assigned use.



Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

==> Early on, there was slight disagreement on what the rules mean and what requirements should be derived from them. Disagreements were resolved.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

==> This document specifies only requirements, not the protocol, implementations are n/a. The document was reviewed by people who are familiar with the rules Regulators adopted.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

==> Document Shepherd is Gabor Bajko. Responsible AD is Pete Resnick.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

==> The document went through 2 WGLCs, all issues raised on the list were resolved.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

==> No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

==> No broader review is seen necessary by the document shepherd.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

==> No issues or concerns with the document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

==> There are two authors, and they both confirmed that the document is in full conformance of BCP 78 and 79 and they have no IPRs to disclose.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

==> Yes, there is an IPR disclosure, filed against wg document version -03 (not by the authors). The wg was made aware of the declaration, but it had no issues with it, as the licensing terms were acceptable (royalty free).

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

==> The wg had intense discussions on the document, and all issues were resolved. There seems to be very solid wg consensus on the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

==> No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

==> No ID nits found in the document.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

==> The document doesn't define any MIB, media type or URI types, no additional formal reviews are seen necessary.

(13) Have all references within this document been identified as either normative or informative?

==> yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

==> no such normative references.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

==> no downward normative references in this document.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

==> No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

==> this document has no requests to IANA.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

==> no new IANA registries requested.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.
==> there are no parts of the document written in a formal language.