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 protected]]
Sent: Friday, June 14, 2013 3:09 PM
To: Weixinpeng
Cc: [email protected]; 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.).
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 protected]<mailto:[email protected]>> 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
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
