I am Still not a fan of basing DB discovery on the LOST protocol. It seems to be way to complicated and I would hope someone can explain how to reconcile the capability with the need. That said the following comments are independent of the LOST protocol.
The introduction should be expanded to identify that there are many ways that a device could get access to a database not just the manually programmed example given. The WSDB DS will very likely be nested. I cannot see Ofcom giving up ownership and authority of its DB discovery process for instance. So a WSDB DS would have to reconcile that a WSD was in the UK regulatory domain and provide a reference to the Ofcom DB Management system. Under current US rules there is no concept of a WSDB DS radios are certified against a database. However a device certified in the USA may travel to other countries and then need to use a WSDB DS. So the other case that needs to be discussed is a device that in some instances has a preconfigured link to a database and the ability to use a WSDB DS in other cases. There may be a situation (and I am making this up for an example) where a device is certified in the US along with a database, certified in Canada along with a database and certified generically in the rest of the world. This device may have a hierarchy where it checks with the US DB first. If it gets denied (because it is outside the regulatory domain) then it tries Canada and if that also fails goes to the WSDB DS. This raises a couple of questions. Is the WDSB DS going to return all "certified" databases in a regulatory domain or only the ones that are appropriate for the device making the query? How is the set of regulatory certified domains mapped to those databases willing to serve the device or the databases the device is willing to go to (This is a business decision)? Wearing my DB provider hat, I only want to (and only will) serve devices for which I have a business relationship with the manufacturer or possibly the owner. Does this process work if the owner of the device is to make the decision rather than the device? Did we cover the correct set of responses from a DB to cover this mechanism? Although the WSDB DS thinks that the device should be associated with a DB the DB does not The DB does not want to serve the device even though it is on the WSDB DS list The Device does not want to work with a DB on the list (how does it know if all it gets is a URL – so radio vendor x is won't work with DB provider y) The device has a preference to work with DB vendor y in as many regulatory domains as possible It seems many of these can be addressed more easily if the device uses a manufacturer provided discovery process (as it will have knowledge of the business relationships) rather than some new global entity that will have to be created, maintained and supported. Which brings me to my final question who owns and operates the WSDB DS and who pays for it? Regards, Peter S. From: Weixinpeng <[email protected]<mailto:[email protected]>> Date: Sunday, February 17, 2013 9:20 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Peter McCann <[email protected]<mailto:[email protected]>> Subject: [paws] [A new PAWS DB Discovery Draft] Hi all, A new draft of DB Discovery has been submitted: http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt Comments are welcome!! --Xinpeng Wei.
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
