Subject: [paws] AD Review of draft-ietf-paws-problem-stmt-usecases-rqmts

From: Pete Resnick <[email-masked]>
Date: Mon, 29 Oct 2012 01:37:55 -0500

Folks,

Off the top, I want to sincerely apologize for the lateness of this 
review. A bunch of day-job things followed by an ill-timed vacation 
conspired to make this very late.

Overall, I want to say that while I have some issues with this document, 
they are almost all of the form that there is *too much* information in 
the document. Section 4 is 19 pages of the document, and for the life of 
me I can't connect up the use cases in section 4 with the requirements 
in section 6. I am inclined to seriously trim down the use cases so that 
it is clear what use case corresponds to what requirement. There is also 
quite a bit of material in sections 1 through 3 that are about 
whitespace itself and the regulatory environment. As I've said before in 
face-to-face meetings and on this list, this protocol, while it is being 
used for access to a whitespace database, has scant little to do with 
whitespace. You don't even need to know much about anything about radio 
to implement this protocol; it's a database access protocol with a set 
of fields returned that happen to have information about whitespace 
usage. So please (to quote Douglas Adams), "Don't panic!" Take the below 
comments as simply an attempt to remove extra unnecessary information; 
as I said, for the most part, that is my main complaint. But I do think 
we want to take a shot at clearing this up before Last Call, let alone 
before IESG Evaluation. Other ADs will not be so kind! :-)

pr

------

Specifics:

1.1.  Introduction to white space

    Academia and Industry have studied
    multiple cognitive radio mechanisms for use in such a scenario.

"Cognitive Radio" is undefined.

    Spectrum useable for data communications, especially wireless
    Internet communications, is scarce. ...

I think everything up to the last two sentences of this paragraph is 
unnecessary and doesn't add to the document

    Any entity that is assigned
    spectrum that is not densely used may be asked to give it up in one
    way or another for more intensive use.  Providing a mechanism by
    which additional users share the spectrum with the assigned user is
    attractive in many bands in many countries.

That's fine

    Television transmission until now has primarily been analog. ...

This paragraph and the figure are completely unneeded.

    The fundamental issue is how to determine for a specific location and
    specific time if any of the spectrum is available for additional use.
    ...

I'm not sure whether the above is necessary or not. I don't see what it 
adds.

1.2.1.  In Scope

    This document applies only to communications required for basic
    service in TV white spaces.

That sentence is just wrong. First, it's worded as if this document is 
about *communications* in TV white spaces. It's obviously not about that 
at all; it applies to *database access for discovery of whitespace 
allocations*. But even there, it's also not at all clear that this 
document applies only to TV white spaces. This protocol is applicable to 
any shared spectrum, whether it is coming from TV white space or 
otherwise. What I think you mean to say is, "This document lays out the 
requirements for accessing a database of information about available 
spectrum, with a specific eye to the use case of TV white spaces. 
Requirements outside of that use case are not accounted for." We don't 
want to say that this document *can't* be used for other such databases; 
it just isn't taking those requirements into account.

2.2.  Terminology

    Database

       In the context of white space and cognitive radio technologies,
       the database is an entity which contains, but is not limited to,

You say, "not limited to". What other kinds of things might be in there?

       current information as required by by the regulatory policies...

The phrase "as required by regulatory policies" is unneeded. The 
information in the database might be required by regulators, or it might 
not. Regulatory policies have nothing to do with the requirements of the 
protocol.

    Device Class

       Identifies classes of devices defined by Regional Regulators,
       ...

Again, "defined by Regional Regulators" should be removed.

       including fixed, mobile, portable, etc...  May also indicate if
       the device is indoor or outdoor.

    Slave Device

       A device which uses the spectrum made available by a master
       device, and cannot query the database directly.

Do you mean "cannot" or "does not"? In other words, if a device has 
direct Internet access and is able to communicate with the database, is 
it by definition a master device?

3.  Prior Work

I didn't find section 3 at all useful. Could someone explain what this 
adds to the document? An understanding of this did not help me in 
section 6, which is what I would expect.

4.  Use cases and protocol services

    There are many potential use cases that could be considered for the
    TV white space spectrum.  ...

So my basic issue with this section (and this paragraph) is that many of 
the use cases are architecturally identical for purposes of the 
requirements. I think a good deal of compression could be done in this 
section.

4.1.1.  White space database discovery

    ...  The master device will need to discover a
    trusted database in the relevant regulatory domain, using the
    following steps:

"Regulatory domain" is unnecessary.

    1.  The master device is connected to the Internet by any means...

That's fine.

        ...other
        than using the white space radio.  A local regulator may identify
        exception cases where a master may initialize over white space
        (e.g. the FCC allows a master to initialize over the TV white
        space in certain conditions).

The rest of this is out of band and not relevant to the protocol.

    Optionally the radio device is pre-programmed with the Internet
    address of at least one trusted database.  The device can establish
    contact with a trusted database using one of the pre-programmed
    Internet addresses and establish a white space network (as described
    in one of the following use cases).

OK.

    Optionally the initial query will be made to a listing approved by
    the national regulator for the domain of operation (e.g. a website
    either hosted by or under control of the national regulator) which
    maintains a list of WS databases and their Internet addresses.  The
    query results in the list of databases and their Internet addresses
    being sent to the master, which then evaluates the response to
    determine if a trusted database can be identified where the master
    device is able to register and receive service from the database.

The above seems identical to the previous paragraph. Can't this 
paragraph be removed?

4.1.2.  Device registration with trusted Database

    Registration may be preliminary to creating a radio network using
    white space; in some regulatory domains, for some device types, it is
    a prerequisite to the use cases below.  The radio network is created
    by a master device.  Before the master device can transmit in white
    space spectrum, it must contact a trusted database where the device
    can learn if any channels are available for it to use.

The above is confusing to me. What does it mean to create the radio 
network before transmitting? And again, why is this relevant to the 
protocol?

                               \|/                            ----------
                                |                             |Database|
                                |                     .---.   /---------
                              |-|---------|          (     ) /
      \|/                     |  Master   |         /       \
       |                   /  |           |========( Internet )
       |                  /   |-----------|         \        /
     +-|----+   (AirIF)                              (      )
     |Master|  /                                      (----)
     |      | /
     +------+

     Figure 2: Example illustration of registration requirement in white
                               space use-case

Master appears twice is this diagram. Are there two masters in this 
model? I don't understand what this means.

    A simplified operational scenario showing registration consists of
    the following steps:

    1.  The master device must register with its most current and up-to-
        date information.  Typically the master device will register
        prior to operating in white space for the first time after power
        up, after changing location by a predetermined distance, and
        after regular time intervals.

Is the above simply an authentication step?

    2.  The master device shall provide to the database during
        registration all information required according to local
        regulatory requirements.  This information may include, but is
        not limited to, the Device ID, serial number assigned by the
        manufacturer the device's location, device antenna height above
        ground, name of the individual or business that owns the device,
        name of a contact person responsible for the device's operation
        address for the contact person, email address for the contact
        person and phone number of the contact person.

Is the above to be specified by the protocol, or is this simply a blob 
of information that has only local meaning? For instance, will the 
database announce the information it needs for registration, or will the 
device simply have to know this out of band? I don't see anything in 
section 6 regarding this.

    3.  The database shall respond to the registration request with an
        acknowledgement code to indicate the success or failure of the
        registration request.  Additional information may be provided
        according to local regulator requirements.

Are there semantics to the acknowldgement code beyond "Registered" and 
"Not registered"? If so, is the IETF defining those?

4.2.  Use cases

4.2.1.  Hotspot: urban Internet connectivity service

First let me say that I can find no difference architecturally between 
this use case and wide-area/rural deployment in 4.2.2. Indeed, the 
diagrams are almost identical. So I see no need to separate this out 
into two sections; they should at least be combined. That said:

    In this use case Internet connectivity service is provided in a
    "hotspot" to local users.  Typical deployment scenarios include urban
    areas where Internet connectivity is provided to local businesses and
    residents, and campus environments where Internet connectivity is
    provided to local buildings and relatively small outdoor areas.

The above seems unimportant. Whether it's a hotspot, or provider to 
campus or local buildings, or wide-area/rural is not important to the 
architecture. They key an Internet access point that wants to talk to 
devices over whitespace spectrum discovering which spectrum to use by 
querying the database.

    This
    deployment scenario is typically characterized by multiple masters
    ...

If this is typical, why is only one master shown in the figure. You'd 
think that would be important to the diagram. However, I suspect it 
isn't important to the architecture and that this discussion about 
multiple masters can be removed.

    (APs or hotspots) in close proximity, with low antenna height, cells
    with relatively small radius (a few kilometers or less), and limited
    numbers of available radio channels.  Many of the masters/APs are
    assumed to be individually deployed and operated, i.e. there is no
    coordination between many of the masters/APs.  The masters/APs in
    this scenario use a TDD radio technology.  Each master/AP has a
    connection to the Internet and may provide Internet connectivity to
    other master and slave devices.

TDD is undefined. AP is undefined. And again, I see nothing in the above 
important to the architecture being discussed.

           Figure 3:

Slaves are labeled as "device". That's confusing.

   1.   ...A local
         regulator may identify exception cases where a master may
         initialize over white space (e.g. the FCC allows a master to
         initialize over TV white space in certain conditions).

This sounds like a different deployment scenario, not the same one.

    3.   The master/AP registers with the trusted database according to
         regulatory domain requirements (see Section 4.1.2).

Regulatory domain requirement are irrelevent. You can strike that part.

    4.   ...The complete set of parameters to be provided
         from the master to the database is specified by the local
         regulator.

No, it's provided by database policy. Local regulators may specify their 
particular database policy, but that's outside of the protocol.

    5.   If the master/AP has met all regulatory domain requirements
         (e.g. been previously authenticated, etc)...

Is there anything beyond authentication here? Importantly, neither the 
master nor the database can understand the semantics of "regulatory 
domain requirements"can they? That's all out of band.

    6.   Once the master/AP has met all regulatory domain requirements
         (e.g. authenticated the WS channel list response message from
         the database, etc)...

Same as above.

         ...the AP selects one or more available WS
         channels from the list.  Prior to initiating transmission, if
         required by local regulation...

It's not "local regulation", it's protocol that would require the 
answer, right?

    7-13.

Except for relaying information about the slaves to the database and how 
frequencies/channels are determined, isn't everything thing else in 7-13 
what a normal device/AP interaction would look like? This can all be 
reduced to one or two points it seems to me.

4.2.2.  Wide-Area or Rural Internet broadband access

As I said above, this appears architecturally identical to 4.2.1.

    A typical deployment scenario is a wide area or rural area, where
    Internet broadband access is provided to local businesses and
    residents from a master (i.e., BS) connected to the Internet.

BS is undefined. Probably best to define it. :-)

4.2.3.  Offloading: moving traffic to a white space network

This example is obfuscated by the mention of "3G" and "YouTube". First 
of all, there is nothing about 3G that is unique to this scenario; the 
desire to use white space instead of any kind of more costly internet 
connection (metered wire service, metered wireless service, metered 
satellite service) is what's relevant. Second, using a widget or an 
online service is also irrelevant; the key is that a high-bandwidth or 
other costly service is to be used. (The mention of "YouTube" is, I 
think, especially inappropriate.) This entire section could use some 
rewriting.

4.2.4.  White space serving as backhaul

    In this use case Internet connectivity service is provided to users
    over a more common wireless standard such as Wi-Fi with white space
    entities providing backhaul connectivity to the Internet.  In a
    typical deployment scenario an end user has a device with a radio
    such as Wi-Fi.  An Internet service provider or a small business
    owner wants to provide Wi-Fi Internet connectivity service to their
    customers.  The location where Internet connectivity service via
    Wi-Fi is to be provided is within the coverage area of a white space
    master (e.g.  Hotspot or Wide-Area/Rural network).  The service
    provider installs a white space slave device and connects it to the
    Wi-Fi access point(s).  Wi-Fi access points with an integrated white
    space slave component may also be used.  This deployment scenario is
    typically characterized by a WS master/AP/BS providing local
    coverage.  The master/AP has a connection to the Internet and
    provides Internet connectivity to slave devices that are within its
    coverage area.  The WS slave device is 'bridged' to a Wi-Fi network
    thereby enabling Internet connectivity service to Wi-Fi devices.  The
    WS Master/AP/BS which has some form of Internet connectivity (wired
    or wireless) queries the database and obtains available channel
    information.  It then provides service using those channels to slave
    devices which are within its coverage area.

    Figure 6 shows an example deployment of this scenario.

                         \|/     white    \|/    \|/   Wi-Fi \|/
                          |      space     |      |           |
                          |                |      |         |-|----|
        |--------|      |-|---------|    |-|------|-|       | Wi-Fi|
        |        |      | Master    |    |  Slave   |       | Dev  |
        |Internet|------| (AP/BS)   |    |  Bridge  |       |------|
        |        |      |           |    | to Wi-Fi |
        |--------|      |-----------|    |----------|        \|/
                                                              |
                                                            |-|----|
                                                            | Wi-Fi|
                                                            | Dev  |
                                                            |------|

                          Figure 6: WS for backhaul

The description of this deployment scenario is not well written, and the 
figure does nothing to help. Aren't the Wi-fi devices supposed to be 
connected to the slave, and then the slave talks to the master? This 
needs some help.

4.2.5.  Rapid deployed network for emergency scenario

    ...  This
    approach does in no way imply such organizations for disaster relief
    must compete on spectrum allocation with other white spaces users,
    but they can. ...

That sentence seems unnecessary.

4.2.6.  Mobility

How does this use case differ architecturally from 4.2.1? Why isn't this 
case just a subcase of 4.2.1, like 4.2.2?

4.2.7.  Indoor Networking

Isn't this just the same as 4.2.1 without geolocation? Again, seems like 
it could be combined and shortened.

5.  Problem Statement

    In Figure 11, note that there could be multiple databases serving
    white space devices.  The databases are country specific since the
    regulations and available spectrum may vary.

Location specific, not country specific, right? It may be that multiple 
countries share a database, or it may be that a single country has 
multiple databases for sub-locales, right? The architecture doesn't 
depend on "country".

5.1.  Global applicability

    The use of TV white space spectrum is currently approved by the FCC
    in the United States.  However regulatory bodies in other countries
    are also considering similar use of available spectrum.  ...

Again, the mention of the regulatory bodies here is unnecessary as it 
doesn't impact this protocol.

    4.  Address regulatory requirements - Each country is likely to have
        regulations that are unique to that country.  The messaging
        interface needs to be flexible to accommodate the specific needs
        of a regulatory body in the country where the white space device
        is operating and connecting to the relevant database.

I would rewrite this to say: "4. Flexible and extensible data structures 
- Different databases are likely to have different requirements for the 
kinds of data required for registration as well as the kinds of data 
returned with available white space. For instance, different regulatory 
bodies might require different information to be passed between the 
database and the device accessing it." Again, don't make the regulatory 
body part of the problem statement; the need to accommodate different 
data is the requirement.

5.4.  Data model definition

    ...
    Use of XML for specifying a data model is an attractive option.  The
    intent is to evaluate the best option that meets the need for use
    between white space devices and databases.

The mention of XML here is premature. Give it as one example (perhaps 
including JSON as another) if you think you need such an example.

6.  Requirements

6.1.  Normative Requirements

       D. Data Model Requirements:

       D.1:  The Data Model MUST support specifying the location of the
             WSD, the uncertainty in meters, the height & its
             uncertainty, and confidence in percentage of the location
             determination. ...

"Location" in the above is ambiguous. You mean the "geographic 
location", right?

             ...The Data Model MUST support both North
             American Datum of 1983 and WGS84.

Neither of these has a reference. Also, if NAD is really a requirement, 
shouldn't there be others listed?

       D.2:  The Data Model MUST support specifying the regulatory domain
             and its corresponding data requirements.

That is poorly written. I don't understand what needs to go in a 
protocol from the above. Don't you just mean that the Data Model MUST be 
extensible?

       D.3:  The Data Model MUST support specifying an ID of the
             transmitter device.  This ID would contain the ID of the
             transmitter device that has been certified by a regulatory
             body for its regulatory domain.  The Data Model MUST support
             a device class.  The Data Model MUST support specifying
             information about the type of RAT of the transmitter device.

What sort of data is an ID? You probably need to mention that. Also 
"RAT" is undefined.

        P. Protocol Requirements:

       P.1:   The protocol MUST provide a mechanism to enable WSD
              discovery.  In some environments, a listing of the approved
              white space databases is maintained by the national
              regulator.  The protocol MUST support discovery of a
              database using a listing approved by a national regulator.

The "national regulator" portion of the requirement is not the 
requirement. What is it about the list a national regulator provides 
that is different, protocol-wise, from any other list from which the WSD 
is discovered?

       P.3:   The protocol MUST support determination of regulatory
              domain governing its current location.

I don't know what that requirement means.

       P.8:   The protocol MUST support the master device registering
              with the database.

What is "registering" independent of authentication/authorization?

       P.10:  The protocol MUST support a channel query request from the
              master device to the database.  The channel query request
              message MUST include parameters as required by local
              regulatory requirement.  These parameters MAY include any
              of the parameters and attributes required to be supported
              in the Data Model Requirements.

Strike the second sentence. Unnecessary.

6.2.  Non-normative requirements

I don't understand what a non-normative requirement is. Are these just 
pre-requisites? Please explain.

I'm guessing that the 2119 language in this section is misused, but let 
me understand what the section is meant to say first.

    O.4:   The master device MUST implement at least one connection
           method to access the database.  The master device MAY contact
           a database directly for service (e.g. as defined by FCC) or
           the master device MAY contact a listing server first followed
           by contact to a database (e.g. as defined by Ofcom).

References needed for FCC and Ofcom if you insist on noting them. (I 
don't think they're necessary.)

    O.5:   The master device MUST obtain an indication about the
           regulatory domain governing operation at its current location,
           i.e. the master device MUST know if it operates under
           regulations from FCC, Ofcom, etc...

That would be completely out of band, correct?

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

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 29 Oct 2012 08:53:01 -0400

Pete,
I don't think we can ignore the "Regulator". You may not need to know what
a radio does or how it works but the database is logically tied to a
Regulator.
In all the cases we are aware of the Database will either be operated by
the Regulator or by an entity (or entities) authorized by a Regulator.
Spectrum use is tightly regulated - the regulator makes the rules. There
are many examples of things that are included in this protocol that you
could argue would not normally be required for a protocol. They are only
there because Regulators require them. You raise a lot of questions on the
requirements and these should probably be resolved before we expend much
more effort on the protocol specifications.
Peter S.

On MonOct/29/12 Mon Oct 29, 2:37 AM, "Pete Resnick"
<[email-masked]> wrote:

>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: Pete Resnick <[email-masked]>
Date: Mon, 29 Oct 2012 13:20:26 -0500

On 10/29/12 7:53 AM, Peter Stanforth wrote:
> there because Regulators require them.

I think you've missed the point. It is certainly clear that we need to 
take into account requirements that come from regulators. But it is the 
requirements that are important, not where they come from. For example, 
in other IETF protocols, we may have requirements from industry that 
certain things are NETCONF manageable. That might not normally be 
required for a protocol, but because they are required by a particular 
industry, they are requirements for our protocol design. That doesn't 
mean that we say, "MUST follow all requirements of the widget industry". 
We say, "MUST be NETCONF manageable." The industry is irrelevant to the 
document; it's the requirement that matters.

Concentrating on the regulator also obfuscates real requirements. 
Regulatory language is almost never in appropriate engineering terms. 
People must figure out what the engineering requirement is from the 
regulatory language. Conversely, if a regulatory statement seems to 
indicate something that is contrary to the correct engineering outcome, 
we have to figure out how to do the engineering with the requirement or 
get the requirement fixed. Knowing it comes from a regulator doesn't 
help us.

There is nothing special, from a protocol engineering perspective, that 
the requirements come from a regulator. Having references to the 
regulator is either inappropriate or is hiding missing information that 
we need to have in the document. Of the items that I specifically 
pointed out in the document, I can find nothing that mentioning the 
regulator adds to the text. If you can point one out that makes a 
difference, please do.

pr