Subject: Re: [paws] Database discovery mechanisms (was: Re Database Discovery Question)

From: Peter Stanforth <[email-masked]>
Date: Fri, 20 Apr 2012 09:31:57 -0400

Just to clarify
US implementation ALLOWS for operator to choose DB. It does not require it.
We have to support various schemes for how the DB to use is determined.
Peter S

There are many more solutions and the choices have more bearing on
commercial and business issues than technical issues. Out of necessity we
built a discovery solution, because we have radios and databases running
in trials in several countries, that is very different from both of those
described.  The solution we chose was as simple and quick as possible
because the goal was to try to get trials up and running, so I would not
offer it up as a direct solution but it does have some interesting
concepts I will outline below. However because the scope of discovery
keeps growing I still think it should be outside the current scope of
PAWS. Lets get a protocol completed and decide if we need to come back and
address this issue.

First issue. For our US solution discovery is not allowed in the context
described below. The radio has to be certified along with the DB(s) that
it will operate with. In the UK they have proposed a national discovery
process that will be managed by the regulator. I can't speak for Ofcom but
I believe they chose this approach to have some control of the databases
that are actually providing access to white space. Thus I don't believe
they will be happy relinquishing control to some UN of database discovery.

Second issue.  The radio vendors we are working with do not want to have
to go to different databases, though they would like the option to choose.
In the US regulation they achieve this by certifying with multiple
databases. In the Uk they would use a business relationship related to the
list provided by Ofcom.

Third issue is who is making the decision?  There seems to be a
presumption that the radio is making the choice. I Strongly reject that.
Here in the US the implemented model allows the network operator, who
purchased the radio, to choose the database. I expect we have to support
both models and maybe others, which further complicates discovery.

Fourth issue is flexibility. One complaint on this forum was how to add or
delete from the possible list. Again the presumption was that the lack of
a discovery mechanism would prevent this.

This is what we did. Step 1 the radios leave the manufacturer
preconfigured with the address(s) of the DB that it can talk to. So today
it is our US database as that is what the device is certified for. Step 2.
The radio always comes to the last known (initially original) DB. The DB
verifies the location and determines if it is within scope. If not it
returns a pointer/link to the device to direct it to a DB that can support
it based on the reported location.  As I said this was done as an
expedient. However I could see a variation of this appealing to a device
manufacturer. 
Assume that every device is preprogrammed to "phone home" the device
manufacturer can then return the pointer/link to the DB or DB discovery
server the device is to use based on the location provided. Several nice
things about this approach. One I don't need to create some UN of Database
discovery mechanisms and, two, the device manufacturer can add/delete
support for DB around the world when and how it sees fit.  Such an
implementation would serve the US market (it would return a list of
certified DB) and Ofcom (it would retune a pointer to the Ofcom DB manager
process). Third this is a very simple, lightweight proposal that does not
need to carry the burden of a process designed for Public Safety
applications (LoST).

So a long way of saying I don't buy the two options as I think there are
many more, much better, options.

Peter S.

On ThuApr/19/12 Thu Apr 19, 5:52 PM, "[email-masked]"
<[email-masked]> wrote:

>➢ it would be useful to actually have some I-Ds proposing a solution for
>discovery
>I guess Subir initiated this thread to find out which solutions might be
>acceptable for the group.
>
>So far we heard about two possible solutions:
>a) LoST (RFC5222), and
>b) (semi-)preconfiguration
>
>With LoST, the master device needs to first discover a LoST server (using
>either DNS, DHCP or it may be preconfigured), then do the query. This
>assumes there is a LoST server which is preconfigured with the boundaries
>the WSDBs can provide answer for. In roaming cases, the LoST server would
>need to be a local one (not just _the_ preconfigured one), as it is
>unlikely that a LoST server in one country would know the WSDBs in other
>countries.
>If the master device does not know what country it is in, it may find
>that out from the WSDB it is told to contact by the LoST server.
>The weak part of this solution I think is the roaming case, where the
>LoST server has to be discovered either by dhcp (we all know the
>limitations of this) or DNS. DNS also has its practical limitations, as
>zone admins may be reluctant to just add U-NAPTR records for a service
>with limited usage. If there could be assumed that the is a global LoST
>server able to answer queries from all over, then this could be a working
>solution. But can we make these assumptions?
>
>The preconfiguration could be as simple as provisioning the master
>devices with a URI, which would contain an up-to-date list of existing
>WSDBs. The device would need to find out which country it is in, then
>query the appropriate db. If there are multiple in that country and
>didn't pick the right one, it could either be redirected to the right one
>or could try itself the other one. The problematic part here is how to
>find out what country it is in. Again, if we assume non-roaming, then it
>is trivial, the problem here is also with the roaming case. If the device
>has map data available, that would help it map its location to a
>country/regulatory_domain.
>
>So, I think both solutions have their weak points, depending on how the
>assumptions we make will match with the global deployments. If we
>conclude that different discovery mechanisms would suit better the
>diversity of use cases, we may not need to pick one mechanism, but go
>with (eg) two.
>
>- Gabor
>
>
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Patil Basavaraj (Nokia-CIC/Dallas)
>Sent: Thursday, April 19, 2012 12:35 PM
>To: [email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [paws] Database Discovery Question
>
>
>I agree that we are jumping off to discuss the solution space.
>The requirement for PAWS is that we need a database discovery mechanism.
>There can be multiple approaches towards this requirement. LoST is one
>option. But there are others as well and it would be useful to actually
>have some I-Ds proposing a solution for discovery than fragmented pieces
>of information and ideas.
>
>-Raj
>
>From: "<ext Rosen>", "[email-masked]" <[email-masked]>
>Date: Thursday, April 19, 2012 1:40 PM
>To: "Das, Subir" <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [paws] Database Discovery Question
>
>We're getting solutions ahead of requirements.
>
>LoST is a solution to a requirement for discovery.
>
>However, the answer to your question is that either we use an existing
>LoST service and add service urns for our purpose, or all the database
>operators in an area cooperate to run one LoST service, or some single
>neutral entity runs it.
>
>Brian
>
>On Apr 19, 2012, at 2:33 PM, Das, Subir wrote:
>
>
>I think that database discovery should be left to each country to define
>based on their own requirements and Whitespace ecosystem.
> 
>By that argument, we should close up shop and let each country define
>their own database query protocol.
> 
>SD> I would not consider both of them at the same level.
> 
>I do not understand how we will satisfy the following:
> 
>If it is an operator managed LoST service (likely) how would it know what
>answer to provide for the other database assuming there is no roaming
>relationship.  And why should the operator provide this, if he is not
>managing the whitespace service.
> 
>
>
>
>From: Rosen, Brian [mailto:[email-masked]]
>Sent: Thursday, April 19, 2012 2:01 PM
>To: Don Joslyn
>Cc: Das, Subir; [email-masked]
>Subject: Re: [paws] Database Discovery Question
> 
><as individual>
>I disagree.
> 
>While local regulation could limit capability for discovery, in general,
>I would like to be able to build devices that find databases based on
>location and type of device.
> 
>It may be, as in say GSM cell phones, that discovery presents a list of
>possibilities, and specific choices get based on things like roaming
>relationships, but to make that work requires standardization.
> 
>See inline for comments
>On Apr 19, 2012, at 1:30 PM, Don Joslyn wrote:
>
>
>
>I don't think PAWS should define discovery, I think the protocol should
>simply start after a device has "found" the correct database to use.
> 
>I feel this way for many reasons:
>1) In the US, a radio is certified to work with one or more specific
>databases. So the device will be pre-configured to contact specific
>databases, no need to implement a discovery service. If the device is
>programmed to work with more than one database provider, the device owner
>will configure which one to use based on the relationship that they have
>established with the database provider (for example, which one they are
>paying to use).
>Discovery would provide the list of (10) databases.  Which one you use
>could be based on existing subscriptions, but could also be based on
>roaming agreements.  Preconfiguration won't work: I build a device that
>is certified to work in the U.S. and the U.K.  It's sold to a U.K.
>customer, who visits the U.S.  The customer's U.K. provider has a roaming
>arrangement with one or more U.S. database operators.  I want that to
>work, even if the device is certified to work in 25 countries.
>Preconfiguration rarely works well in global, mobile environments.  You
>can do it, but I want a standardized discovery mechanism.
> 
>
>
>
>2) Discovery services like LoST are based on location, but the device's
>relationship with a database service is not known or considered. While it
>may seem simple to configure LoST or similar service to point to a
>database service based on location, how do you point to the one that the
>customer has a relationship with, for example, paid to use? I do realize
>that this may not be an issue in every country.
>See roaming above.  You may have configuration for your home database,
>but not a roaming database.  Also, I expect arrangements in some other
>countries will be simpler than the U.S.
> 
>
>
>
>3) If PAWS defines a globally applicable discovery process and either
>picks an existing protocol (like LoST) or designs one, most likely it
>would include a centrally based discovery service. What entity will be
>responsible for hosting and configuring the central discovery service?
>How will PAWS define this as a global solution, and deal with the
>politics between countries?
>LoST is designed to not require a central anything.  It's distributed.
>It cleverly avoids the political mess.  The designers were mindful of
>these issues.
> 
>I'm waving my hands a bit, but it's a very good answer for discovery of
>location sensitive servers.
> 
>4) Some radio manufacturers do not have very much ROM to include even
>more code on their device. I'm concerned that discovery will consume even
>more space on the radio, space that they may not even have.
>Not an argument that gets you any traction in the IETF.  ROM is cheap.
>Have more.  All it takes is one service call to wipe out savings in ROM.
>
>
>
>5) I believe that defining discovery will take more time than defining
>the protocol between the WSDB and WSD.
>Nah.  We do this for lots of protocols.  If we decide to use LoST, it
>will be very easy.
>
>
>
> 
>I think that database discovery should be left to each country to define
>based on their own requirements and Whitespace ecosystem.
>By that argument, we should close up shop and let each country define
>their own database query protocol.
>
>
>
>
>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws

---

From: Peter McCann <[email-masked]>
Date: Fri, 20 Apr 2012 14:03:08 +0000

I think at least part of the reason the WSD and WSDB have to be certified
together today is that we have no standards for the interface between them.
So, they have to be viewed together as a "black box".

Once we have PAWS, it will be possible for a device owner to easily switch
database providers, and to more easily support roaming to different jurisdictions.
This is what imposes the requirement for a discovery protocol.

-Pete

Peter Stanforth wrote:
> commercial and business issues than technical issues. Out of necessity
> we built a discovery solution, because we have radios and databases
> running in trials in several countries, that is very different from
> both of those described.  The solution we chose was as simple and
> quick as possible because the goal was to try to get trials up and
> running, so I would not offer it up as a direct solution but it does
> have some interesting concepts I will outline below. However because
> the scope of discovery keeps growing I still think it should be
> outside the current scope of PAWS. Lets get a protocol completed and
> decide if we need to come back and address this issue.
> 
> First issue. For our US solution discovery is not allowed in the
> context described below. The radio has to be certified along with the
> DB(s) that it will operate with. In the UK they have proposed a
> national discovery process that will be managed by the regulator. I
> can't speak for Ofcom but I believe they chose this approach to have
> some control of the databases that are actually providing access to
> white space. Thus I don't believe they will be happy relinquishing
> control to some UN of database discovery.
> 
> Second issue.  The radio vendors we are working with do not want to
> have to go to different databases, though they would like the option
> to choose.
> databases. In the Uk they would use a business relationship related to
> the list provided by Ofcom.
> 
> Fourth issue is flexibility. One complaint on this forum was how to
> add or delete from the possible list. Again the presumption was that
> the lack of a discovery mechanism would prevent this.
> 
> preconfigured with the address(s) of the DB that it can talk to. So
> today it is our US database as that is what the device is certified
> for. Step 2.
> The radio always comes to the last known (initially original) DB. The
> DB verifies the location and determines if it is within scope. If not
> it returns a pointer/link to the device to direct it to a DB that can
> support it based on the reported location.  As I said this was done as
> an expedient. However I could see a variation of this appealing to a
> device manufacturer.
> manufacturer can then return the pointer/link to the DB or DB
> discovery server the device is to use based on the location provided.
> Several nice things about this approach. One I don't need to create
> some UN of Database discovery mechanisms and, two, the device
> manufacturer can add/delete support for DB around the world when and how it sees fit.
> Such an implementation would serve the US market (it would return a
> list of certified DB) and Ofcom (it would retune a pointer to the
> Ofcom DB manager process). Third this is a very simple, lightweight
> proposal that does not need to carry the burden of a process designed
> for Public Safety applications (LoST).
> 
> So a long way of saying I don't buy the two options as I think there
> are many more, much better, options.
> 
> Peter S.
> 
>> ➢ it would be useful to actually have some I-Ds proposing a solution
>> for discovery I guess Subir initiated this thread to find out which
>> solutions might be acceptable for the group.
>> 
>> With LoST, the master device needs to first discover a LoST server
>> (using either DNS, DHCP or it may be preconfigured), then do the query.
>> This assumes there is a LoST server which is preconfigured with the
>> boundaries the WSDBs can provide answer for. In roaming cases, the LoST
>> server would need to be a local one (not just _the_ preconfigured one),
>> as it is unlikely that a LoST server in one country would know the
>> WSDBs in other countries. If the master device does not know what
>> country it is in, it may find that out from the WSDB it is told to
>> contact by the LoST server. The weak part of this solution I think is
>> the roaming case, where the LoST server has to be discovered either by
>> dhcp (we all know the limitations of this) or DNS. DNS also has its
>> practical limitations, as zone admins may be reluctant to just add
>> U-NAPTR records for a service with limited usage. If there could be
>> assumed that the is a global LoST server able to answer queries from
>> all over, then this could be a working solution. But can we make these
>> assumptions?
>> 
>> didn't pick the right one, it could either be redirected to the right
>> one or could try itself the other one. The problematic part here is how
>> to find out what country it is in. Again, if we assume non-roaming,
>> then it is trivial, the problem here is also with the roaming case. If
>> the device has map data available, that would help it map its location
>> to a country/regulatory_domain.
>> 
>> Patil Basavaraj (Nokia-CIC/Dallas) Sent: Thursday, April 19, 2012 12:35
>> PM To: [email-masked]; [email-masked] Cc: [email-masked]
>> I agree that we are jumping off to discuss the solution space. The
>> requirement for PAWS is that we need a database discovery mechanism.
>> have some I-Ds proposing a solution for discovery than fragmented
>> pieces of information and ideas.
>> 
>> -Raj
>> 
>> However, the answer to your question is that either we use an
>> existing LoST service and add service urns for our purpose, or all
>> the database operators in an area cooperate to run one LoST service,
>> or some single neutral entity runs it.
>> 
>> Brian
>> 
>> I think that database discovery should be left to each country to
>> define based on their own requirements and Whitespace ecosystem.
>> 
>> If it is an operator managed LoST service (likely) how would it know
>> what answer to provide for the other database assuming there is no
>> roaming relationship.  And why should the operator provide this, if
>> he is not managing the whitespace service.
>> 
>> 
>> 
>> 
>> While local regulation could limit capability for discovery, in
>> general, I would like to be able to build devices that find databases
>> based on location and type of device.
>> 
>> I feel this way for many reasons: 1) In the US, a radio is certified to
>> work with one or more specific databases. So the device will be
>> pre-configured to contact specific databases, no need to implement a
>> discovery service. If the device is programmed to work with more than
>> one database provider, the device owner will configure which one to use
>> based on the relationship that they have established with the database
>> provider (for example, which one they are paying to use). Discovery
>> would provide the list of (10) databases.  Which one you use could be
>> based on existing subscriptions, but could also be based on roaming
>> agreements.  Preconfiguration won't work: I build a device that is
>> certified to work in the U.S. and the U.K.  It's sold to a U.K.
>> customer, who visits the U.S.  The customer's U.K. provider has a
>> roaming arrangement with one or more U.S. database operators.  I want
>> that to work, even if the device is certified to work in 25 countries.
>> relationship with a database service is not known or considered. While
>> it may seem simple to configure LoST or similar service to point to a
>> database service based on location, how do you point to the one that
>> the customer has a relationship with, for example, paid to use? I do
>> realize that this may not be an issue in every country. See roaming
>> above.  You may have configuration for your home database, but not a
>> roaming database.  Also, I expect arrangements in some other countries
>> will be simpler than the U.S.
>> 
>> 
>> 
>> 
>> would include a centrally based discovery service. What entity will
>> be responsible for hosting and configuring the central discovery service?
>> more code on their device. I'm concerned that discovery will consume
>> even more space on the radio, space that they may not even have. Not an
>> argument that gets you any traction in the IETF.  ROM is cheap. Have
>> more.  All it takes is one service call to wipe out savings in ROM.
>> 
>> 
>> 
>> 5) I believe that defining discovery will take more time than
>> defining the protocol between the WSDB and WSD.
>> I think that database discovery should be left to each country to
>> define based on their own requirements and Whitespace ecosystem.

---

From: Peter Stanforth <[email-masked]>
Date: Fri, 20 Apr 2012 10:30:14 -0400

That is not a valid assumption.
The FCC did not consider how the DB and WSD communicate, it simply treats
the pair as a system.
Under the rules a TVWS  radio get part 15 certification in two parts,  by
passing the typical emissions tests and demonstrating correct interworking
with a database. The resulting FCC ID is based on the combination. Note
that a device can be certified with more than one DB by repeating the
second part of the test process. There is no ability to say radio A,
certified with DB X, can talk to DB Y because radio B was certified with
Y.
Peter S.

---

From: Peter McCann <[email-masked]>
Date: Fri, 20 Apr 2012 15:05:16 +0000

Once we have a PAWS standard, the certification process should be
greatly simplified, and it should be much easier to certify a device
with multiple databases simultaneously.

-Pete

Peter Stanforth wrote:
> The FCC did not consider how the DB and WSD communicate, it simply
> treats the pair as a system.
> Under the rules a TVWS  radio get part 15 certification in two parts,
> by passing the typical emissions tests and demonstrating correct
> interworking with a database. The resulting FCC ID is based on the
> combination. Note that a device can be certified with more than one DB
> by repeating the second part of the test process. There is no ability
> to say radio A, certified with DB X, can talk to DB Y because radio B
> was certified with Y.
> Peter S.
> 
>> I think at least part of the reason the WSD and WSDB have to be
>> certified together today is that we have no standards for the interface
>> between them. So, they have to be viewed together as a "black box".
>> 
>> Once we have PAWS, it will be possible for a device owner to easily
>> switch database providers, and to more easily support roaming to
>> different jurisdictions.
>>> Just to clarify US implementation ALLOWS for operator to choose DB. It
>>> does not require it. We have to support various schemes for how the DB
>>> to use is determined. Peter S
>>> 
>>> have to go to different databases, though they would like the
>>> option to choose.
>>> databases. In the Uk they would use a business relationship related
>>> to the list provided by Ofcom.
>>> 
>>> presumption that the radio is making the choice. I Strongly reject
>>> that. Here in the US the implemented model allows the network
>>> operator, who purchased the radio, to choose the database. I expect we
>>> have to support both models and maybe others, which further
>>> complicates discovery.
>>> 
>>> add or delete from the possible list. Again the presumption was
>>> that the lack of a discovery mechanism would prevent this.
>>> 
>>> for. Step 2. The radio always comes to the last known (initially
>>> original) DB. The DB verifies the location and determines if it is
>>> within scope. If not it returns a pointer/link to the device to direct
>>> it to a DB that can support it based on the reported location.  As I
>>> said this was done as an expedient. However I could see a variation of
>>> this appealing to a device manufacturer. Assume that every device is
>>> preprogrammed to "phone home" the device manufacturer can then return
>>> the pointer/link to the DB or DB discovery server the device is to use
>>> based on the location provided. Several nice things about this
>>> approach. One I don't need to create some UN of Database discovery
>>> mechanisms and, two, the device manufacturer can add/delete support
>>> for DB around the world when and how it sees fit. Such an
>>> certified DB) and Ofcom (it would retune a pointer to the Ofcom DB
>>> manager process). Third this is a very simple, lightweight proposal
>>> that does not need to carry the burden of a process designed for
>>> Public Safety applications (LoST).
>>> 
>>> So a long way of saying I don't buy the two options as I think
>>> there are many more, much better, options.
>>> 
>>> Peter S.
>>> 
>>>> (using either DNS, DHCP or it may be preconfigured), then do the
>>>> query. This assumes there is a LoST server which is preconfigured
>>>> with the boundaries the WSDBs can provide answer for. In roaming
>>>> cases, the LoST server would need to be a local one (not just _the_
>>>> preconfigured one), as it is unlikely that a LoST server in one
>>>> country would know the WSDBs in other countries. If the master device
>>>> does not know what country it is in, it may find that out from the
>>>> WSDB it is told to contact by the LoST server. The weak part of this
>>>> solution I think is the roaming case, where the LoST server has to be
>>>> discovered either by dhcp (we all know the limitations of this) or
>>>> DNS. DNS also has its practical limitations, as zone admins may be
>>>> reluctant to just add U-NAPTR records for a service with limited
>>>> usage. If there could be assumed that the is a global LoST server
>>>> able to answer queries from all over, then this could be a working
>>>> devices with a URI, which would contain an up-to-date list of
>>>> existing WSDBs. The device would need to find out which country it is
>>>> in, then query the appropriate db. If there are multiple in that
>>>> country and didn't pick the right one, it could either be redirected
>>>> to the right one or could try itself the other one. The problematic
>>>> part here is how to find out what country it is in. Again, if we
>>>> assume non-roaming, then it is trivial, the problem here is also with
>>>> the roaming case. If the device has map data available, that would
>>>> help it map its location to a country/regulatory_domain.
>>>> 
>>>> So, I think both solutions have their weak points, depending on
>>>> how the assumptions we make will match with the global
>>>> deployments. If we conclude that different discovery mechanisms
>>>> would suit better the diversity of use cases, we may not need to
>>>> pick one mechanism, but go with (eg) two.
>>>> 
>>>> - Gabor
>>>> 
>>>> 
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>> Of Patil Basavaraj (Nokia-CIC/Dallas) Sent: Thursday, April 19, 2012
>>>> 12:35 PM To: [email-masked]; [email-masked] Cc:
>>>> [email-masked] Subject: Re: [paws] Database Discovery Question
>>>> 
>>>> 
>>>> There can be multiple approaches towards this requirement. LoST is
>>>> one option. But there are others as well and it would be useful to
>>>> actually have some I-Ds proposing a solution for discovery than
>>>> fragmented pieces of information and ideas.
>>>> 
>>>> -Raj
>>>> 
>>>> By that argument, we should close up shop and let each country
>>>> define their own database query protocol.
>>>> 
>>>> general, I would like to be able to build devices that find
>>>> databases based on location and type of device.
>>>> 
>>>> It may be, as in say GSM cell phones, that discovery presents a list
>>>> of possibilities, and specific choices get based on things like
>>>> roaming relationships, but to make that work requires standardization.
>>>> 
>>>> See inline for comments
>>>> I don't think PAWS should define discovery, I think the protocol
>>>> should simply start after a device has "found" the correct database
>>>> to use.
>>>> 
>>>> I feel this way for many reasons: 1) In the US, a radio is certified
>>>> to work with one or more specific databases. So the device will be
>>>> one database provider, the device owner will configure which one to
>>>> use based on the relationship that they have established with the
>>>> database provider (for example, which one they are paying to use).
>>>> Discovery would provide the list of (10) databases.  Which one you
>>>> use could be based on existing subscriptions, but could also be based
>>>> on roaming agreements.  Preconfiguration won't work: I build a device
>>>> that is certified to work in the U.S. and the U.K.  It's sold to a
>>>> U.K. customer, who visits the U.S.  The customer's U.K. provider has
>>>> a roaming arrangement with one or more U.S. database operators.  I
>>>> want that to work, even if the device is certified to work in 25
>>>> countries. Preconfiguration rarely works well in global, mobile
>>>> environments. You can do it, but I want a standardized discovery
>>>> mechanism.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 2) Discovery services like LoST are based on location, but the
>>>> device's relationship with a database service is not known or
>>>> considered. While it may seem simple to configure LoST or similar
>>>> service to point to a database service based on location, how do you
>>>> point to the one that the customer has a relationship with, for
>>>> example, paid to use? I do realize that this may not be an issue in
>>>> every country. See roaming above.  You may have configuration for
>>>> your home database, but not a roaming database.  Also, I expect
>>>> arrangements in some other countries will be simpler than the U.S.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>  picks an existing protocol (like LoST) or designs one, most likely
>>>> it  would include a centrally based discovery service. What entity
>>>> will  be responsible for hosting and configuring the central
>>>> discovery service? How will PAWS define this as a global solution,
>>>> and deal with the politics between countries? LoST is designed to not
>>>> require a central anything.  It's distributed. It cleverly avoids the
>>>> political mess.  The designers were mindful of  these issues.
>>>> 
>>>> I'm waving my hands a bit, but it's a very good answer for discovery
>>>> of location sensitive servers.
>>>> 
>>>> even more space on the radio, space that they may not even have. Not
>>>> an argument that gets you any traction in the IETF.  ROM is cheap.
>>>> Nah.  We do this for lots of protocols.  If we decide to use LoST,
>>>> it will be very easy.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> By that argument, we should close up shop and let each country
>>>> define their own database query protocol.
>>>> 
>>>> 
>> 
>> 
>> 
>