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]> 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
