Subject: Re: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

From: Pete Resnick <[email-masked]>
Date: Wed, 2 Jan 2013 19:02:48 -0600

Tony,

Thanks for the new version. At first glance, it looks like a good edit. 
I'll do a thorough review once the WG confirms that this one is good to go.

Chairs, let me know when this has had enough review. I'd especially like 
to hear from folks like Peter Stanforth and others who had concerns that 
my suggestions might have removed too much from the document. Does this 
version satisfy everyone?

Thanks for giving this a go, and a happy new year to everyone.

pr

On 12/21/12 12:39 PM, Anthony Mancuso wrote:
> PAWS list members,
>
> I just submitted a new version of the PAWS Use Cases & Requirements 
> doc for review and discussion.
>
> The latest draft (v. 09):
>
>     * incorporates the suggestions contained in the post by Pete
>       Resnick, AD, which included, among other things, recommendation
>       to coordinate architecturally-and protocol-common use cases
>     * adds a new use case (local TV broadcast)
>     * Deleted security threat 5 and added language to security
>       considerations to match the protocol security considerations
>       that have evolved in the WG
>     * Clarified protocol normative requirement 6.3 to: "The protocol
>       MUST support determination of regulatory domain governing its
>       current location."
>    *
>       Cleaned up language and usage:
>       consistent use of primary, secondary users
>       changed "channel" availability references to "spectrum"
>       availability where appropriate
>       deleted references specific to TV band and generalized these to
>       radio spectrum
>       changed references to regulatory domain to rule set of
>       regulatory domain as appropriate to clarify that the latter
>       controls device behavior regardless of country (Brazil adopts US
>       "FccWhitespace2010" rule set)
>       cleaned up language and syntax throughout
>
> Thanks for any feedback,
>
> Tony Mancuso
>

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

---

From: <[email-masked]>
Date: Tue, 8 Jan 2013 21:57:50 +0000

Thanks Tony for generating this new version of the document. The overlapping use cases have been merged, a new use case has been added and the language was cleaned up throughout the document.
I would like to ask people to review it and send to the list any issues. So far we got feedback from Nancy (thanks!), this new revision captures her comments. But I would like to hear from others as well, before we ask the AD to review it again. It only takes 10-15min to review.
If we do not hear any concerns or objections from anyone until next Monday (Jan 14th), we'll assume the group is fine with the document and we'll ask for the AD review.

Thanks, Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Pete Resnick
Sent: Wednesday, January 02, 2013 5:03 PM
To: Anthony Mancuso
Cc: [email-masked]
Subject: Re: [paws] Fwd: I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

Tony,

Thanks for the new version. At first glance, it looks like a good edit. I'll do a thorough review once the WG confirms that this one is good to go.

Chairs, let me know when this has had enough review. I'd especially like to hear from folks like Peter Stanforth and others who had concerns that my suggestions might have removed too much from the document. Does this version satisfy everyone?

pr

I just submitted a new version of the PAWS Use Cases & Requirements doc for review and discussion.

  *   incorporates the suggestions contained in the post by Pete Resnick, AD, which included, among other things, recommendation to coordinate architecturally-and protocol-common use cases
  *   adds a new use case (local TV broadcast)
  *   Deleted security threat 5 and added language to security considerations to match the protocol security considerations that have evolved in the WG
  *   Clarified protocol normative requirement 6.3 to: "The protocol MUST support determination of regulatory domain governing its current location."

  *   Cleaned up language and usage:
consistent use of primary, secondary users
changed "channel" availability references to "spectrum" availability where appropriate
deleted references specific to TV band and generalized these to radio spectrum
changed references to regulatory domain to rule set of regulatory domain as appropriate to clarify that the latter controls device behavior regardless of country (Brazil adopts US "FccWhitespace2010" rule set)
cleaned up language and syntax throughout
Thanks for any feedback,

Tony Mancuso

--

Pete Resnick <http://www.qualcomm.com/~presnick/><http://www.qualcomm.com/~presnick/>

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 9 Jan 2013 09:22:34 -0800

Gabor,

I thought this was a no-negatives review;-)  I read through the doc last
night and could only find irrelevant nits to carp about.  You've done a
good job of getting the 'how' issues out of the way of the 'what'
ones.  

On Tue, 2013-01-08 at 21:57 +0000, [email-masked] wrote:
> Thanks Tony for generating this new version of the document. The
> overlapping use cases have been merged, a new use case has been added
> and the language was cleaned up throughout the document. 
> 
> I would like to ask people to review it and send to the list any
> issues. So far we got feedback from Nancy (thanks!), this new revision
> captures her comments. But I would like to hear from others as well,
> before we ask the AD to review it again. It only takes 10-15min to
> review.
> 
> If we do not hear any concerns or objections from anyone until next
> Monday (Jan 14th), we’ll assume the group is fine with the document
> and we’ll ask for the AD review.
> 
>  
> 
> Thanks, Gabor
> 
>  
> 
> Subject: Re: [paws] Fwd: I-D Action:
> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
> 
> 
>  
> 
> Tony,
> 
> Thanks for the new version. At first glance, it looks like a good
> edit. I'll do a thorough review once the WG confirms that this one is
> good to go.
> 
> Chairs, let me know when this has had enough review. I'd especially
> like to hear from folks like Peter Stanforth and others who had
> concerns that my suggestions might have removed too much from the
> document. Does this version satisfy everyone?
> 
>         Resnick, AD, which included, among other things,
>         recommendation to coordinate architecturally-and
>         protocol-common use cases
> changed references to regulatory domain to rule set of regulatory
> domain as appropriate to clarify that the latter controls device
> behavior regardless of country (Brazil adopts US "FccWhitespace2010"
> rule set)
> 
> 
> Pete Resnick <http://www.qualcomm.com/~presnick/>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 11 Jan 2013 16:28:21 -0500

First of all I apologize for taking so  long to review this.  Good Job! While I could poke at a couple of areas I like the fact that this is concise and to the point so I would much prefer to leave it alone and move on.
Regards,
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, December 21, 2012 12:10 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Protocol to Access WS database Working Group of the IETF.

Title           : Protocol to Access White Space (PAWS) Database: Use Cases and Requirements
Author(s)       : Anthony Mancuso
                          Basavaraj Patil
Filename        : draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt
Pages           : 27
Date            : 2012-12-21

Abstract:
   [Editor's Note: This version is submitted for review.  A final, post-
   review version is anticipated that will supersede this version].

   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.

   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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-problem-stmt-usecases-rqmts-09

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: <[email-masked]>
Date: Mon, 14 Jan 2013 21:20:07 +0000

Thanks for everyone who reviewed the draft. It seems the draft is acceptable as it is, so let's go for the AD review.
Tony already mentioned that he made some minor wording changes to the draft to capture Nancy's comments, once Tony uploads the new version, we'll ask our AD to review it again.

-          Gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Peter Stanforth
Sent: Friday, January 11, 2013 1:28 PM
To: [email-masked]
Subject: Re: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt

Abstract:

---

From: Anthony Mancuso <[email-masked]>
Date: Mon, 14 Jan 2013 14:16:57 -0800

Gabor,

I just uploaded v. 10 to IETF for AD review.

Thanks to all for their review and comments.

Tony

On Mon, Jan 14, 2013 at 1:20 PM, <[email-masked]> wrote:

>  Thanks for everyone who reviewed the draft. It seems the draft is
> acceptable as it is, so let’s go for the AD review.****
>
> Tony already mentioned that he made some minor wording changes to the
> draft to capture Nancy’s comments, once Tony uploads the new version, we’ll
> ask our AD to review it again.****
>
> ** **
>
> **-          **Gabor****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Peter Stanforth
> *Sent:* Friday, January 11, 2013 1:28 PM
> *To:* [email-masked]
> *Subject:* Re: [paws] I-D Action:
> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt****
>
> ** **
>
> First of all I apologize for taking so  long to review this.  Good Job!
> While I could poke at a couple of areas I like the fact that this is
> concise and to the point so I would much prefer to leave it alone and move
> on.****
>
> Regards,****
>
> Peter S.****
>
> ** **
>
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Friday, December 21, 2012 12:10 PM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *[paws] I-D Action:
> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt****
>
> ** **
>
> ** **
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.****
>
> This draft is a work item of the Protocol to Access WS database Working
> Group of the IETF.****
>
> ** **
>
>                 Title           : Protocol to Access White Space (PAWS)
> Database: Use Cases and Requirements****
>
>                 Author(s)       : Anthony Mancuso****
>
>                           Basavaraj Patil****
>
>                 Filename        :
> draft-ietf-paws-problem-stmt-usecases-rqmts-09.txt****
>
>                 Pages           : 27****
>
>                 Date            : 2012-12-21****
>
> ** **
>
> Abstract:****
>
>    [Editor's Note: This version is submitted for review.  A final, post-**
> **
>
>    review version is anticipated that will supersede this version].****
>
> ** **
>
>    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.****
>
> ** **
>
>    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 IETF datatracker status page for this draft is:****
>
>
> ****
> ** **
> There's also a htmlized version available at:****
>
> http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-09*
> ***
>
> ** **
>
> A diff from the previous version is available at:****
>
>
> ****
> ** **
> ** **
> Internet-Drafts are also available by anonymous FTP at:****
>
> ftp://ftp.ietf.org/internet-drafts/****
>
> ** **
>
> _______________________________________________****
>
> paws mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/paws****
>
> ** **
>

---

From: Pete Resnick <[email-masked]>
Date: Mon, 14 Jan 2013 16:25:01 -0600

I'm on it.

On 1/14/13 4:16 PM, Anthony Mancuso wrote:
> On Mon, Jan 14, 2013 at 1:20 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     acceptable as it is, so let's go for the AD review.
>
>     Tony already mentioned that he made some minor wording changes to
>     the draft to capture Nancy's comments, once Tony uploads the new
>     version, we'll ask our AD to review it again.
>
>     - Gabor
>
>     *From:* [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *ext Peter Stanforth
>     *To:* [email-masked] <mailto:[email-masked]>
>     First of all I apologize for taking so  long to review this.  Good
>     Job! While I could poke at a couple of areas I like the fact that
>     this is concise and to the point so I would much prefer to leave
>     it alone and move on.
>
>     Regards,
>
>     Peter S.
>
>     *From: *"[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *"[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     directories.
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Anthony Mancuso <[email-masked]>
Date: Tue, 15 Jan 2013 08:07:32 -0800

Pete,

Here are my detailed notes on what I did for version 9 in response to your
earlier comments (current version 10 made a few changes in response to
Nancy's recent comments). Vince also made changes in the Section 5
Requirements subsections. I thought I had sent this out to the list, but
apparently I only sent a summary of the changes I made (as shown in the
sumary section below). Sorry for the late post (it's a long one).

Tony Note: Use Case & Requirements Doc edits:

Summary of what I did to create version 9:

Created xml version 09 (copied and pasted and organized 08 text file to
create xml version 09)
Deleted threat 5 - we don't want to try to protect spectrum. Other threats
are mostly man in the middle, which HTTPS will help protect against.
Added language to security considerations to match the protocol security
considerations that have evolved in the WG.
Clarified protocol normative requirement 6.3 to: "The protocol MUST support
determination of regulatory domain governing its current location."
Cleaned up language:
  consistent use of primary, secondary users,
  changed "channel" availability references to "spectrum" availability
where appropriate
  changed "the database" to "a database" to avoid implication of one white
space databae
  deleted references specific to TV band and generalized these to radio
spectrum
  eliminated unnecessary references to regulatory domain
  cleaned up language and syntax throughout.

Specific Responses to Pete Resnicks comments:
http://www.ietf.org/mail-archive/web/paws/current/msg01316.html

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.

-- Added link to article.

   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

-- made recommended deletion.

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

This paragraph and the figure are completely unneeded.

-- made recommended deletion

   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.

-- Deleted.

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.

-- Rephrased the sentence to: "This document covers the requirements for a
protocol to allow a device to access a database to obtain spectrum
availability information. Such a protocol should allow a device to perform
the following actions:"

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?

-- see next response.

      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.

-- rephrased to: "The database is an entity that contains current
information about available spectrum at any given location and time as well
as other types of information related to spectrum availability and usage."

   Device Class

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

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

-- made recommended deletion.

      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?

-- Rephrased to: A device that queries the database through a Master Device.

-- Also deleted regulatory reference in definition of White Space Device;
rephrased to: "A device that uses white space spectrum as a secondary user.
A white space device can be an access point, base station, a portable
device, a wireless microphone, or other type of 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.

-- Deleted Section 3.

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.

-- made recommended deletion

   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.
-- made recommended deletion.

   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?

-- made recommended deletion

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?

-- Simplified the above paragraph and removed reference to creating a radio
network: "In some regulatory domains, the master device must register with
the trusted database before it queries the database for available spectrum.
aDifferent regulatory domains may have different device registration
requirements."

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

-- removed second master connected through air to other master.

   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?
-- No, this is simply data transfer.

   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.

-- Section 5, D1 - D6 show that the protocol must support the transmission
of this data (in the protocol specification doc, these are the required
fields if the device transmits a registration request message). No
requirement for the DB to announce the required information to the device.

   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?

-- I reworded to show that the acknowledgment occurs on success; else
error. The actual values for acknowledgment and error are specified in the
protocol doc.

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:

combine use cases 3.2.1 (Urban hotspot), 3.2.2 (rural WAN), 3.2.6
(Mobility), 3.2.7 (Indoor Networking) 3.2.8 (Machine to Machine)

   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.

-- Rephrased the paragraph and combined uses cases 1 and 2 (urban hotspot
and rural WAN).

   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.

-- made recommended deletion to refer to only one master in the simple case
depicted.

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

-- Deleted use of these terms in the discussion.

          Figure 3:

Slaves are labeled as "device". That's confusing.
-- Changed to "slave device".

  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.

-- deleted referrence to init over WS.

   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.

-- stricken as recommended.

   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.

-- deleted reference to regulator policies.

   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.

-- deleted reference to regulatory requirements.

   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.

-- deleted 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?

-- Deleted reference to regulatory domain.

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

-- eliminated this separate treatent of rural WAN (including base stations);
-- as noted in Pete's general remarks and later remarks on use cases,
consolidated common architectural/topological use cases (hotpots, WAN,
mobility, indoor network) into one common case and rewrote the description
and tightened up the step.

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.

-- Rewrote and re-drew the figure as recommended.

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.

-- deleted sentence as recommended.

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?

-- Agreed. Combined with master/slave whitespace network

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.

-- Agreed Moved into use case 1

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

-- Changed to regulatory specific (location based was mentioned in earlier
sentence). The intent here I think was to indicate that different dbs might
follow different regluatory domain (country) rules, but the protocol should
be independent from them.

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.

-- deleted reference

   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.

-- Rewritten as recommended.

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.

-- deleted reference to XML. No need to mention possible data model
implementations here.

6.  Requirements

---- Asked Vince to look at these.

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?

--changed to geolocation.

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

*****************************

TODO: VInce's responses:
A couple of thoughts.
 - If there is an opportunity, we should distinguish between "regulatory
domain" and "rule set", where:
   - regulatory domain is based on where the device is
   - rule set is a set of requirements that govern device behavior

(rather than combining them into a single phrase of "regulatory domain
requirements"). A "rule set" may be applicable in multiple domains.

In some of Pete's comments, he thinks that how a device behaves within a
regulatory domain is out of band. I tend to agree, but it is still useful
to have the Database be able to tell the Device which rule set is
applicable at its location. Thus, the use-case/requirements should allow
for that to be communicated from the Database to the Device. Why?

 - The Device may know where it is (latitude/longitude), but it most likely
will not know which country it's in.
 - Just knowing the country may not help, if it's one that just approved
use of White Space. BUT if a new country
   (e.g., Brazil) adopts the US rule set, the Database can tell the Device
that it can use "FccWhitespace2010" rules,
   the device will just work.

I believe the original doc had some statements like the above, so we don't
want to completely delete all text that refer to "regulator".

Please also see below for my Normative/Non-Normative answers

Perhaps here's an opportunity to say that the database can inform the
device of the applicable rule set.
A database may support multiple domains and multiple rule sets, so we don't
want the phrasing to be too limiting.

-- TODO (amancuso): I added ruleset information below in different places.
I'll have to go through the doc and see if there are other places where we
might want to mention rule set communication by db to device.

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.

It does, in the sense that the device needs to know which rule set....
Let's just use WGS84 for the protocol. Delete NAD83. The Database can do
any required conversions.

--Added in mention of rule set; deleted NAD83 (
http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html)
--Added this to the global applicability point 3:

"Note that although a device may know its geolocation, it may not know the
country or regulatory domain that it is in. Further, even if the device
knows this information, it may not be sufficient for the device to know its
expected behaviour in its domain of operation since one domain may adopt a
rule set for white space device operation from another regulatory domain
(Brazil may adopt the "FccWhitespace2010" US rule set). To allow the global
use of white space devices in different countries (whatever the regulatory
domain), the protocol should support the Database communicating applicable
rule set information to the white space device."

      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?

This somewhat addresses my original point. It's beyond just extensible,
since it's beneficial for the Device to know which set of rules to use.
Perhaps it's a surprise to Pete, because the need has not been articulated
well enough.

-- Changed to: "The Data Model MUST support specifying the data and other
applicable requirements of the rule set that applies to the white space
device at its current location."

      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.

FCC certification ID is an example ID, but there could be other IDs for
other certification bodies.
Serial Number is also ID.

This requirement is really two things:
 - Fields that identify a device (Serial number, certification IDs)
 - Fields that describe device characteristics (device class, radio access
technology (RAT), etc.)

In the Protocol Document, the data model is named "DeviceDescriptor".

 -- Rewrote: "The Data Model MUST support device description data that
identifies a device (serial number, certification IDs, etc.) and describes
device characteristics (device class, Radio Access technology (RAT), etc.)."

       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?

I would agree with Pete... Just stating that "listing service" is an option
is sufficient.

There's no requirement that the "listing approved by a national regulator"
be used for discovery. It can be use to validate.

In other words, the Device can contact a database it knows about and, in
parallel, contact the national regulator to make sure that database is
listed. This way, we can avoid chicken/egg.

The need to contact a listing service is "baked into" the Device. It is
just behavior that it needs to implement. It's not part of the protocol.

-- I rolled this up into one requirement and reworded to: "The address of a
database (e.g., in form of a URI) can be preconfigured in a master device.
The master device MUST be able to contact a database using a pre-configured
database address. The master device may validate the database against a
list of approved database maintained by a regulatory body."

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

I don't know what that requirement means.

This is explained above with the need to know the set of governing rules.
So it must support a Database informing the Device of regulatory domain and
governing rules.

--- Changed this to: "he protocol must support the database informing the
master of the regulatory rules (rule set) that applies to the master device
(or any slave devices on whose behalf the master is contacting the
database) at the current location or the master (or slave) device(s)."

-- Note that in view of the earlier comments, I didn't see a need to
mention a db requirement to inform the device of the regulatory body (since
the determinative data is the ruleset (may be the current or a "foreign"
domain).

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

What is "registering" independent of authentication/authorization?

As explained elsewhere, (could back-reference?) this is contact information
of owner/operator, device geolocation, antenna characteristics, etc. It is
orthogonal to authentication/authorization. I think Pete realized this at
the F2F, so it should not be controversial.

-- added xref to registration section.

      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

Change channel to "available spectrum".

-- done here and in next available spectrum response paragraph.

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.

These are trying to describe the system as a whole, containing requirements
/ behavior on the Device and Database, independent of the Protocol. That
should be explained, then ask for guidance on how to frame these and
whether they are needed.

-- Added this lead-in sentence: "This section contains functional
characteristics of the white space database/devices system, independent of
the specific requriements of the protocol for communication between the
white space database and devices."

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

Agree with Pete. Again, this is a requirement on the device.

-- deleted references to regulators. OK to talk about device requriements
here now that the intent of this section is clearer.

   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?

Not completely, as I explained above. It is beneficial to have the Device
know which rule set to use.
In particular, if it gets a ruleset it does not understand, it cannot
operate.

-- Changed this to "The master device MUST obtain an information on the
rule set of the regulatory body that applies to the master device at its
current location (and/or the location of any slave devices on whose behalf
the master device is operating)."

On Mon, Jan 14, 2013 at 2:25 PM, Pete Resnick <[email-masked]>wrote:

>> acceptable as it is, so let’s go for the AD review.
>>
>> ask our AD to review it again.
>>
>>
>>
>> -          Gabor
>>
>>
>>
>> on.
>> Group of the IETF.
>> Database: Use Cases and Requirements
>>
> paws mailing [email-masked]://www.ietf.org/mailman/listinfo/paws
>
>
> --
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 15 Jan 2013 10:52:28 -0800

Tony,

>   changed "channel" availability references to "spectrum" availability

I don't think we want to grasp this one in this version, but keep the
extensibility options open:  most of the protocols that we'd imagine in
this space use TDMA MACs (IEEE 802.16, TIA LTE, ...).  So 'availability'
might not be different channel or spectrum, but rather an unused
timeslice.

---

From: Anthony Mancuso <[email-masked]>
Date: Tue, 15 Jan 2013 12:23:20 -0800

Thanks Rex. This is a important clarification that I agree we should keep
in mind (and keep our options open).