Re: [paws] draft-wei-paws-database-discovery-01

["Zhulei (A)" <[e-mail]>]

Hi,

Thinks occur to me, and provide the ideas before really get it.

I supposed that DB as service to discover should be an Internet service, but not sure any more by looking at proposed text  in section 4.1.1 of paws protocol-05.

Some detail implementations occur to me if I can seriously think over the proposal:

1.      IF regulatory seems to maintain a location and DB list mapping in dominated area? IF regulatory seems maintain the DB URL list of other regulatory domain(“S”)?

I would still think proposal in section 4.1.1 of paws-protocol-05 is about a very short term considerations, should be not exactly same proposal as that in Wei’s DB discovery protocol. So, the motivations and the scenarios have not been cleared.


2.      The implementations of section 4.1.1 of paws-potocol-05 is not ready actually, and even not discussed before. I am not able to image the interfaces and message as implementation issues, as they are all about a protocol.


3.      Still not ready to accept HTTP 302/301 method to reply more than one referring destinations. I think this idea is not about complexity,  just wrong.

Best regards,
Zhu Lei
Huawei
Wireless network research department
E-mail address: [e-mail]
Phone: [phone]
Mobile: [phone]

发件人: Weixinpeng
发送时间: 2013年6月8日 15:50
收件人: Vincent Chen
抄送: Mark Jones; [e-mail]; Peter McCann; Zhulei (A); Malyar, John P
主题: RE: [paws] draft-wei-paws-database-discovery-01

Hi Vince, All
         I think the business relationships between master device vendor, regulatory body and database operator is very important to decide how to deploy database discovery mechanism further,
so maybe we should have a discuss about it and have a more clear description of these relationships, can anyone provide some information about this? Thanks!


-Xinpeng




From: Vincent Chen [mailto:[e-mail]]
Sent: Thursday, June 06, 2013 4:08 PM
To: Weixinpeng
Cc: Mark Jones; [e-mail]; Peter McCann; Zhulei (A)
Subject: Re: [paws] draft-wei-paws-database-discovery-01

Xinpeng,


On Wed, Jun 5, 2013 at 8:30 PM, Weixinpeng <[e-mail]<mailto:[e-mail]>> wrote:
Hi Vince, ,
         I am not quite clear about how OUTSIDE_COVERAGE works, if the database is in charge of returning a list of alternate database with OUTSIDE_COVERAGE error, does it means the database has to
maintain some information, such as coverage area, of other databases? And how it works when databases are managed by different companies?

This alternate list is optional, so it's up to the database, business arrangements, and, possibly, regulatory requirements.

Because the return value here is very much like what you are proposing, I was exploring whether we should just add a ListDatabase method to the PAWS protocol such that the device just needs to understand one protocol. This would allow:

 - A database to serve as both listing functionality (if it wants) as well as the spectrum-availability functionality
 - A server can choose to implement only the ListDatabase functionality

In the second case, it would be equivalent to your proposal, just that the protocol messages would be in the same JSONRPC format as the PAWS protocol, rather than the LoST XML format.

(If we were to add the method, I think we should remove the listing from OUTSIDE_COVERAGE error).


         If a master moves from USA to UK, can the database that the master originally connected return available database in UK to master?

That should be allowed.


         Another question is, if a Database Listing server is used, what interface will be deployed between master and Database Listing server, is there an existing one, or a new one should be devised?

It should be the same one. This simplifies the device implementation.


         Finally, when HTTP redirect is provided in the protocol, can you explain it to me when “DbUpdateSpec” be used and when HTTP redirect will be used, if database wants to provide an alternate datebase?

Great question. There was some thought that HTTP redirect can only return a single URL without additional "attributes", so is less flexible in case we wanted to convey more information about the change. On the other hand, DbUpdateSpec does add a bit more complexity.

I think there was also some concern that HTTP redirect is at the outer layer, so does not pass through any hand-shake that might have been required by a WSDB via the INIT_REQ mechanism.

So...does the simplicity of HTTP redirect outweigh the benefits?

-vince


         Thanks!
-Xinpeng