Subject: [paws] considerations about a seperated discovery mechanism and an integrated one.

From: Weixinpeng <[email-masked]>
Date: Fri, 14 Jun 2013 06:30:36 +0000

Hi all,
         Here are some of my considerations of database discovery mechanism on differences between the independent LoST based mechanism and the mechanism integrated in PAWS protocol.
         (1) In the LoST protocol, an architecture for a global, scalable, resilient, and administratively distributed system for mapping geographic location information to URLs has been provided [refer to RFC5582],
and this architecture can be used for LoST based database discovery mechanism, so it can be sure the discovery mechanism can be used globally. But for this mechanism how the "Forest Guide" should be deployed
is an important issue to be satisfied.
        (2) For the scheme that integrates discovery mechanism totally in PAWS protocol document, there are also some considerations. Firstly, I think it is better of this "Standards Track " document only focus on the PAWS protocol
and let the discovery mechanism not standardized, and this can give more freedom on how to provide discovery procedure in different regulatory domain; secondly, the mechanism described in paws protocol seems not scalable very well, may be some more description needs to be provided.

-Xinpeng

---

From: Vincent Chen <[email-masked]>
Date: Fri, 14 Jun 2013 00:09:08 -0700

Xinpeng,

Thanks. Let's then focus on getting the PAWS protocol to a sufficient
state, not for discovery, but to support preconfiguration that is robust to
change.
Preconfiguration needs to support both Database URLs and Listing Server
URLs (as required by Ofcom/ETSI).

Let's focus on Section 4.1
 1. A Device MAY have one or more Database URLs preconfigured
 2. A Device MAY have one or more List Servers preconfigured (those
approved by regulators)
 3. To support changes, PAWS response messages MAY contain databaseChange
parameter that includes
    alternate Database URLs and Devices SHOULD replace its entry for the
responding Database with the alternates
 4. Error handling is described on how the Device should try its list of
Database URLs in case it fails to contact a Database
 5. When a regulator requires a Listing Server, a Device must make sure
that the DB it gets answers from is on that list.

There is NO statement about a Device implementing additional logic to
select amongst its list of preconfigured URLs, since
that's completely Device-side behavior (e.g., caching, having prioritized
preferred lists, etc.).

Are there any objects to any of these steps?

-----------------
Separately, in Section 5.15, when a Device is outside the coverage area of
a Database, the Database MUST return an OUTSIDE_COVERAGE
error and MAY include a list of alternate Databases.

This is not intended to be full discovery, but could provide some
flexibility before discovery is completely defined.

Is this the step you have concerns with? or are you referring to another
section?

Thanks.

-vince

On Thu, Jun 13, 2013 at 11:30 PM, Weixinpeng <[email-masked]> wrote:

>  Hi all,****
>
>          Here are some of my considerations of database discovery
> mechanism on differences between the independent LoST based mechanism and
> the mechanism integrated in PAWS protocol.****
>
>          (1) In the LoST protocol, an architecture for a global, scalable,
> resilient, and administratively distributed system for mapping geographic
> location information to URLs has been provided [refer to RFC5582],****
>
> and this architecture can be used for LoST based database discovery
> mechanism, so it can be sure the discovery mechanism can be used globally.
> But for this mechanism how the “Forest Guide” should be deployed****
>
> is an important issue to be satisfied.****
>
>         (2) For the scheme that integrates discovery mechanism totally in
> PAWS protocol document, there are also some considerations. Firstly, I
> think it is better of this “Standards Track “ document only focus on the
> PAWS protocol****
>
> and let the discovery mechanism not standardized, and this can give more
> freedom on how to provide discovery procedure in different regulatory
> domain; secondly, the mechanism described in paws protocol seems not
> scalable very well, may be some more description needs to be provided. ***
> *
>
> ** **
>
> ** **
>
> -Xinpeng****
>

-- 
-vince

---

From: Weixinpeng <[email-masked]>
Date: Mon, 17 Jun 2013 02:13:40 +0000

Hi Vince,
         The following statement seems ok to me. And I think a separate discovery document is needed.
         There is a question, when the Database returns an OUTSIDE_COVERAGE error and includes a list of alternate Databases, how does database know the alternate databases?
         Thanks.

-Xinpeng

From: Vincent Chen [mailto:[email-masked]]
Sent: Friday, June 14, 2013 3:09 PM
To: Weixinpeng
Cc: [email-masked]; Peter McCann; Zhulei (A); Malyar, John P
Subject: Re: considerations about a seperated discovery mechanism and an integrated one.

Xinpeng,

Thanks. Let's then focus on getting the PAWS protocol to a sufficient state, not for discovery, but to support preconfiguration that is robust to change.
Preconfiguration needs to support both Database URLs and Listing Server URLs (as required by Ofcom/ETSI).

Let's focus on Section 4.1
 1. A Device MAY have one or more Database URLs preconfigured
 2. A Device MAY have one or more List Servers preconfigured (those approved by regulators)
 3. To support changes, PAWS response messages MAY contain databaseChange parameter that includes
    alternate Database URLs and Devices SHOULD replace its entry for the responding Database with the alternates
 4. Error handling is described on how the Device should try its list of Database URLs in case it fails to contact a Database
 5. When a regulator requires a Listing Server, a Device must make sure that the DB it gets answers from is on that list.

There is NO statement about a Device implementing additional logic to select amongst its list of preconfigured URLs, since
that's completely Device-side behavior (e.g., caching, having prioritized preferred lists, etc.).

-----------------
Separately, in Section 5.15, when a Device is outside the coverage area of a Database, the Database MUST return an OUTSIDE_COVERAGE
error and MAY include a list of alternate Databases.

This is not intended to be full discovery, but could provide some flexibility before discovery is completely defined.

Is this the step you have concerns with? or are you referring to another section?

Thanks.

-vince

On Thu, Jun 13, 2013 at 11:30 PM, Weixinpeng <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

-Xinpeng

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Sun, 16 Jun 2013 22:18:01 -0700

Hi Xinpeng,

On Sun, Jun 16, 2013 at 7:13 PM, Weixinpeng <[email-masked]> wrote:

>  Hi Vince, ****
>
>          The following statement seems ok to me. And I think a separate
> discovery document is needed.****
>
>          There is a question, when the Database returns an
> OUTSIDE_COVERAGE error and includes a list of alternate Databases, how does
> database know the alternate databases?
>

Good question. Presumably, it would depend on business relationships
between the databases and trust that the returned database(s)
are certified by the application regulator.

In a domain that requires the use of a Listing Server, the device must
still check the alternate database(s) with the Listing Server.

A flow might be:

 1. Device is in regulatory domain X (but does not know it), but contacts a
Database A in Y
 2. Database Y returns OUTSIDE_COVERAGE error, suggesting the use of
Database B
 3. Device contacts Database B, returning available spectrum and a ruleset
that indicates the device is in domain X
 4. Device uses its (preconfigured) Listing Server for X to determine
whether Database B is valid
 5. If so, Device can use the available spectrum returned by B

(The device may do any sort of caching it desires to try to start with the
"right" database for the next query).

-vince

---

From: Peter McCann <[email-masked]>
Date: Mon, 17 Jun 2013 13:25:18 +0000

Vincent,

Do you imagine that the protocol used to check with the listing service
is also PAWS?

-Pete

Vincent Chen wrote:
> OUTSIDE_COVERAGE error and includes a list of alternate Databases, how
> does database know the alternate databases?
> 
> 
> between the databases and trust that the returned database(s) are
> certified by the application regulator.
> 
>  1. Device is in regulatory domain X (but does not know it), but
> contacts a Database A in Y  2. Database Y returns OUTSIDE_COVERAGE
> error, suggesting the use of Database B  3. Device contacts Database
> B, returning available spectrum and a ruleset that indicates the
> device is in domain X  4. Device uses its (preconfigured) Listing
> Server for X to determine whether Database B is valid  5. If so,
> Device can use the available spectrum returned by B
> 
> (The device may do any sort of caching it desires to try to start with
> the "right" database for the next query).
> 
> -vince

---

From: Vincent Chen <[email-masked]>
Date: Mon, 17 Jun 2013 07:59:32 -0700

Pete,

> Do you imagine that the protocol used to check with the listing service

I'm not yet convinced it should be PAWS, but just wanted to float the idea,
since the
the messages are so similar, namely:

 - Location-aware service
 - Ability to express a list of (name, url) pairs in the response
 - Preconfiguration of some "root" server

I just don't see how a deployment would work without preconfiguration of
some sort.
I think it might be confusing to define a protocol that we don't know how
to make real.

Even if we were to add it to PAWS, though, it would be a separate set of
functionalities, such that
 - A Database MAY implement only the LIsting service
 - A Database MAY implement only the Spectrum service
 - A Database MAY implement both

A Database implementing the Listing service may consult other Listing
services to minimize retry logic on Devices.

-vince