Vince, Gabor, It is perhaps useful for this discussion, and for the development of the discovery protocol, to distribute to the PAWS group the UK requirements in this area. These requirements are captured in the draft of the ETSI Harmonised Standard:
* At start up and before initiating any transmissions the Master WSD shall locate and consult a listing of approved WSDBs relevant to its geographical domain. [The Master WSD shall not transmit if it cannot consult the list]. * In order for the master WSD to continue to use an approved WSDB, it shall also reconsult this listing in accordance with the periodicity, N minutes relevant to its geographical domain of operation. N will be specified in the same listing as the approved WSDBs. * A master WSD shall not request operational parameters from (i.e., query) a WSDB that is not on the list of approved WSDBs relevant to its geographical domain. * Once the time specified (N) has expired, the master WSD shall consult the listing of approved WSDBs again relevant to its geographical domain before contacting a WSDB. * If the list is not accessible after the time specified by N has expired, the WSD shall o continue to use the list that it already holds, and o reconsult the weblisting at least as frequently as once every 2 hours thereafter but not more frequently than once per hour until such time as when the list can be accessed Secondly, I wonder whether it would be better to keep the UE behaviour with regards to discovery and update of database list out of this protocol specification. That is, the draft-ietf-paws-protocol would make the assumption that the device has the URI of an approved database and not would worry about how it got it. It looks to me that some of the requirements you discuss below could be left implementation dependent, and others would be addressed by the database discovery protocol. Regards, Cesar From: [email protected] [mailto:[email protected]] On Behalf Of Vincent Chen Sent: 04 April 2013 20:26 To: [email protected] Cc: [email protected] Subject: Re: [paws] Database Discovery: static provisioning Gabor, Acknowledged. I'll take another stab at the additional points on how to maintain the lists. On Mon, Apr 1, 2013 at 10:05 AM, <[email protected]<mailto:[email protected]>> wrote: Vince, This is a good start, however I think it may worth adding some more context to it. For instance, that some regulators certify a limited number of databases for operation in WS; that some regulators plan to maintain a website listing all approved databases, others may not. The document also needs to address how to keep the preconfigured list of databases up-to-date. Eg, when a preconfigured certified DB, which the master used to contact, is going to shut down/go out of business/close down. In case a listing web site exists, should the master every now and then check if its preconfigured list of DBs matches with the list on the web site, and update accordingly. Master error handling: if one of the DB on in its preconfigured list is contacted, and there is no response, or there is an error response (eg 102 unsupported), what should the master do next. What if none of the preconfigured DBs work. The behavior to some of the points above may be obvious, but I think it still needs to be spelled out. - gabor From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of ext Vincent Chen Sent: Wednesday, March 27, 2013 10:10 AM To: [email protected]<mailto:[email protected]> Subject: [paws] Database Discovery: static provisioning All, At the F2F, it was decided to update the language in the draft-ietf-paws-protocol to explicitly allow static provisioning, while leaving room to adopt dynamic provisioning, when it's defined. Here is the proposed language. Comments are welcomed. Thanks -vince ------------------------------ 4.1. Database Discovery The Device MUST determine the URI for the Database before it can send PAWS messages. The Device MAY be provisioned statically with the URI of one or more Databases. The Device SHOULD be provisioned with the URI of all the databases for which it is certified or otherwise permitted to operate. The Database MAY redirect a PAWS request by returning a HTTP 3xx response, as defined by HTTP/1.1 [RFC2616]. The Database MUST provide the redirect URI in the Location header of the 3xx response, and the Device MUST handle redirects by using the Location header provided by the Database. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the Database that returns the redirect response before following the redirect. Additionally, the Device MUST authenticate the Database indicated in the redirect. Because the Device may communicate with the Database without user interaction and because the Device authenticates the Database, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, which is an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods. The Device MAY obtain the URI of one or more Databases dynamically from authorized and authenticated entities. The Device SHOULD use dynamic provisioning of Database URI when the mechanism is defined. -- -vince ________________________________ ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ******************************************************************************************************************
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
