Subject: Re: [paws] Database Discovery: static provisioning

From: <[email-masked]>
Date: Mon, 1 Apr 2013 17:05:26 +0000

Vince,

This is a good start, however I think it may worth adding some more context to it. For instance, that some regulators certify a limited number of databases for operation in WS; that some regulators plan to maintain a website listing all approved databases, others may not.

The document also needs to address how to keep the preconfigured list of databases up-to-date.
Eg, when a preconfigured certified DB, which the master used to contact, is going to shut down/go out of business/close down.
In case a listing web site exists, should the master every now and then check if its preconfigured list of DBs matches with the list on the web site, and update accordingly.
Master error handling: if one of the DB on in its preconfigured list is contacted, and there is no response, or there is an error response (eg 102 unsupported), what should the master do next.
What if none of the preconfigured DBs work.

The behavior to some of the points above may be obvious, but I think it still needs to be spelled out.

-          gabor

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Vincent Chen
Sent: Wednesday, March 27, 2013 10:10 AM
To: [email-masked]
Subject: [paws] Database Discovery: static provisioning

All,

At the F2F, it was decided to update the language in the draft-ietf-paws-protocol to explicitly allow static provisioning, while leaving room to adopt dynamic provisioning, when it's defined.

Here is the proposed language. Comments are welcomed. Thanks

-vince

------------------------------

4.1.  Database Discovery

   The Device MUST determine the URI for the Database before it can send
   PAWS messages.  The Device MAY be provisioned statically with the URI
   of one or more Databases.  The Device SHOULD be provisioned with the
   URI of all the databases for which it is certified or otherwise
   permitted to operate.

   The Database MAY redirect a PAWS request by returning a HTTP 3xx
   response, as defined by HTTP/1.1 [RFC2616].  The Database MUST
   provide the redirect URI in the Location header of the 3xx response,
   and the Device MUST handle redirects by using the Location header
   provided by the Database.  When redirecting, the Device MUST observe
   the delay indicated by the Retry-After header.  The Device MUST
   authenticate the Database that returns the redirect response before
   following the redirect.  Additionally, the Device MUST authenticate
   the Database indicated in the redirect.  Because the Device may
   communicate with the Database without user interaction and because
   the Device authenticates the Database, when the response code is 301
   (Moved Permanently), the Device MAY redirect without asking a user
   for confirmation, which is an exception to the HTTP/1.1 [RFC2616]
   requirements for HTTP POST methods.

   The Device MAY obtain the URI of one or more Databases dynamically
   from authorized and authenticated entities.  The Device SHOULD use
   dynamic provisioning of Database URI when the mechanism is defined.

---

From: Vincent Chen <[email-masked]>
Date: Thu, 4 Apr 2013 12:25:37 -0700

Gabor,

Acknowledged. I'll take another stab at the additional points on how to
maintain the lists.

On Mon, Apr 1, 2013 at 10:05 AM, <[email-masked]> wrote:

>  Vince,****
>
> ** **
>
> This is a good start, however I think it may worth adding some more
> context to it. For instance, that some regulators certify a limited number
> of databases for operation in WS; that some regulators plan to maintain a
> website listing all approved databases, others may not.****
>
> ** **
>
> The document also needs to address how to keep the preconfigured list of
> databases up-to-date. ****
>
> Eg, when a preconfigured certified DB, which the master used to contact,
> is going to shut down/go out of business/close down.****
>
> In case a listing web site exists, should the master every now and then
> check if its preconfigured list of DBs matches with the list on the web
> site, and update accordingly.****
>
> Master error handling: if one of the DB on in its preconfigured list is
> contacted, and there is no response, or there is an error response (eg 102
> unsupported), what should the master do next. ****
>
> What if none of the preconfigured DBs work.****
>
> ** **
>
> The behavior to some of the points above may be obvious, but I think it
> still needs to be spelled out.****
>
> ** **
>
> **-          **gabor****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Vincent Chen
> *Sent:* Wednesday, March 27, 2013 10:10 AM
> *To:* [email-masked]
> *Subject:* [paws] Database Discovery: static provisioning****
>
> ** **
>
> All,****
>
> ** **
>
> At the F2F, it was decided to update the language in the
> draft-ietf-paws-protocol to explicitly allow static provisioning, while
> leaving room to adopt dynamic provisioning, when it's defined.****
>
> ** **
>
> Here is the proposed language. Comments are welcomed. Thanks****
>
> ** **
>
> -vince****
>
> ** **
>
> ------------------------------****
>
>
> ****
>
> ** **
>
> 4.1.  Database Discovery****
>
> ** **
>
>    The Device MUST determine the URI for the Database before it can send**
> **
>
>    PAWS messages.  The Device MAY be provisioned statically with the URI**
> **
>
>    of one or more Databases.  The Device SHOULD be provisioned with the***
> *
>
>    URI of all the databases for which it is certified or otherwise****
>
>    permitted to operate.****
>
> ** **
>
>    The Database MAY redirect a PAWS request by returning a HTTP 3xx****
>
>    response, as defined by HTTP/1.1 [RFC2616].  The Database MUST****
>
>    provide the redirect URI in the Location header of the 3xx response,***
> *
>
>    and the Device MUST handle redirects by using the Location header****
>
>    provided by the Database.  When redirecting, the Device MUST observe***
> *
>
>    the delay indicated by the Retry-After header.  The Device MUST****
>
>    authenticate the Database that returns the redirect response before****
>
>    following the redirect.  Additionally, the Device MUST authenticate****
>
>    the Database indicated in the redirect.  Because the Device may****
>
>    communicate with the Database without user interaction and because****
>
>    the Device authenticates the Database, when the response code is 301***
> *
>
>    (Moved Permanently), the Device MAY redirect without asking a user****
>
>    for confirmation, which is an exception to the HTTP/1.1 [RFC2616]****
>
>    requirements for HTTP POST methods.****
>
> ** **
>
>    The Device MAY obtain the URI of one or more Databases dynamically****
>
>    from authorized and authenticated entities.  The Device SHOULD use****
>
>    dynamic provisioning of Database URI when the mechanism is defined.****
>
> ** **
>

-- 
-vince

---

From: Cesar Gutierrez <[email-masked]>
Date: Mon, 8 Apr 2013 12:34:46 +0000

Vince, Gabor,

It is perhaps useful for this discussion, and for the development of the discovery protocol, to distribute to the PAWS group the UK requirements in this area. These requirements are captured in the draft of the ETSI Harmonised Standard:

*        At start up and before initiating any transmissions the Master WSD shall locate and consult a listing of approved WSDBs relevant to its geographical domain. [The Master WSD shall not transmit if it cannot consult the list].

*        In order for the master WSD to continue to use an approved WSDB, it shall also reconsult this listing in accordance with the periodicity, N minutes relevant to its geographical domain of operation. N will be specified in the same listing as the approved WSDBs.

*        A master WSD shall not request operational parameters from (i.e., query) a WSDB that is not on the list of approved WSDBs relevant to its geographical domain.

*        Once the time specified (N) has expired, the master WSD shall consult the listing of approved WSDBs again relevant to its geographical domain before contacting a WSDB.

*        If the list is not accessible after the time specified by N has expired, the WSD shall

o   continue to use the list that it already holds, and

o   reconsult the weblisting at least as frequently as once every 2 hours thereafter but not more frequently than once per hour until such time as when the list can be accessed

Secondly, I wonder whether it would be better to keep the UE behaviour with regards to discovery and update of database list out of this protocol specification. That is, the draft-ietf-paws-protocol would make the assumption that the device has the URI of an approved database and not would worry about how it got it. It looks to me that some of the requirements you discuss below could be left implementation dependent, and others would be addressed by the database discovery protocol.

Regards,
Cesar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: 04 April 2013 20:26
To: [email-masked]
Cc: [email-masked]
Subject: Re: [paws] Database Discovery: static provisioning

Gabor,

Acknowledged. I'll take another stab at the additional points on how to maintain the lists.

On Mon, Apr 1, 2013 at 10:05 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Vince,

-          gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Vincent Chen
Sent: Wednesday, March 27, 2013 10:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] Database Discovery: static provisioning

All,

-vince

4.1.  Database Discovery

--
-vince

________________________________

******************************************************************************************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use of the addressee only.

If you have received this email in error please notify the originator of the message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments at your own risk.

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: Vincent Chen <[email-masked]>
Date: Wed, 10 Apr 2013 12:30:19 -0700

Cesar,

Thanks for your input. I agree that we should not get into details of
dynamic discovery in the current protocol specification.
We do, however, probably need to put in enough details on preconfiguration
to have the specification be sufficiently stand-alone.

In the meantime, I've taken another stab at this section addressing some of
the concerns raised by Gabor.
Comments are welcomed from all.

-vince

--------------------------------

4.1.  Database Discovery

   Different regulators may have different requirements for the approval
   and operation of databases, such as:

   o  A regulator may only allow a limited number of certified databases
      to operate.  It also may require the certification of each device-
      to-database pairing.
   o  A regulator may maintain a trusted website that lists all approved
      databases.  It also may mandate how devices use the listing
      service.
   o  A regulator may allow each database to define its own terms of
      use, so that, for example, an approved device may not be able to
      access all approved databases.

   Prior to sending PAWS messages, a Device MUST determine the URI for a
   Database that provides service at its current location.

   o  A Device SHOULD support operation in any regulatory environment.

   Preconfiguration

   The Device MAY be provisioned statically with the URI of one or more
   Databases.  For operation in regulatory domains that do not have a
   listing server, the Device SHOULD be provisioned with the URI of all
   the databases for which it is certified or otherwise permitted to
   operate.  The Device also MAY be provisioned with the URI of listing
   servers approved by regulators.  To adapt to changes to the list of
   certified or approved databases, the Device SHOULD be able to update
   its preconfigured lists of databases and listing servers.  When the
   preconfigured list of databases is provided by a listing service, the
   Device SHOULD check the service periodically to update its list.  The
   time between such updates SHALL be no longer than one week, or any
   update interval required by the applicable regulatory domain,
   whichever is shorter.

   Dynamic Discovery

   The Device MAY obtain the URI of one or more Databases dynamically
   from authorized and authenticated entities.  The Device SHOULD use
   dynamic provisioning of Database URIs when the mechanism is defined.
   The Device MUST use dynamic provisioning in regulatory domains that
   do not allow static provisioning.

   Error Handling

   Whether the Device's list of databases is preconfigured or obtained
   dynamically, the Device SHOULD select an alternate database from the
   list if:

   o  A database is unreachable or does not respond.
   o  A database returns an UNSUPPORTED error (see Error Codes
      (Section 5.13)), which may indicate that the database does not
      support the regulatory domain where the device is located.

   If a suitable database cannot be contacted, the Device MUST NOT
   operate in white space spectrum.  If the Device is already operating
   when it fails to contact a suitable database, and if the applicable
   regulatory domain provides a grace period, the Device may continue to
   operate during such period, but must cease operation at or before the
   expiration of the grace period.  If a grace period is not provided by
   the applicable regulatory domain, an operating Device that fails to
   contact a suitable database MUST cease operation immediately.

   Redirects

   The Database MAY redirect a PAWS request by returning a HTTP 3xx
   response (as defined by HTTP/1.1 [RFC2616]).  The Database MUST
   provide the redirect URI in the Location header of the 3xx response,
   and the Device MUST handle redirects by using the Location header
   provided by the Database.  When redirecting, the Device MUST observe
   the delay indicated by the Retry-After header.  The Device MUST
   authenticate the Database that returns the redirect response before
   following the redirect.  Also, the Device MUST authenticate the
   Database indicated in the redirect.  Since the Device may communicate
   with a Database (which it authenticated) without user interaction,
   when the response code is 301 (Moved Permanently), the Device MAY
   redirect without asking a user for confirmation (note that this
   represents an exception to the HTTP/1.1 [RFC2616] requirements for
   HTTP POST methods).