PAWS Monday 1510 Gabor & Brian (chairs) Note well We have more people than last time, also regulatory people. Information on availability of shared spectrum would be welcome. 2 presentations on agenda: solutions document, then database discovery Problem statement, use cases and requirements published as 6953. Solution doc in WGLC WSDB discovery individual submission Vince, solution document presentation Thanks to lots of people who jumped on the list lately to clean up doc; a couple of issues left Currently -06, some proposed changes to go into -07, some open items Protocol Overview: 6 phases. Not changed since last time. Changes from -03: Database discovery: defined preconfiguration Support for ETSI-EN-301-598 rules Updated reference, JSON-RPC, jCard Name changes Database Discovery: Preconfiguration Try to define a system that is workable before dynamic discovery is fully defined. Static provisioning of database URLs Static provisioning of listing services All response messages allow Database to indicate change to Database URL Enables device to reconfigure itself ETSI Support Added "requestType" parameter to AVAIL_SPECTRUM_REQ Support "Generic Slave" request Added parameters IANA Registry sections Updated JSON encoding: jCard Original draft withdrawn, replaced with draft-ietf-jcardcal-jcard Name changes Method names prefixed with "spectrum.paws." Proposed changes for -07 to resolve issues from list Slave device definition: remove any reference to "geo-location", simply say any device that uses master Pete Resnick sent message today saying no problem, copy terminology from 6953. Make sure two documents are not out of sync. Making definition more of a role is what you want. Brian Rosen: want to copy from the RFC if possible Vince: this additional text was copied from RFC, now changing it PeteR: the geolocation bit did not appear in the terminology section of RFC, rest might be a clean copy Reference generic JSON-RPC error codes, e.g., -32700 for "parse error" No objections Name changes power spectral density over a specified bandwidth, Logical "AND" bandwidth -> psdBandwidth maxPowerDBm -> maxPsdDbmPerBandwidth No objections Listing server scenario Possible bootstrap scenario, but not the only one. Database may return regulatory domain. PeteR: isn't this backward? Should consult listing service first PeteMcCann: should defer this call flow until we have visited the discovery service. Need to figure out who is authorized to tell you what domain you are in Brian Rosen: Need to have discussion of use cases. We are talking past each other. Ray Bellis: would also like to see discovery service, listing service separate from PAWS protocol Vince: we want to know if it's ok to give this scenario in the document Brian: answer is no. We don't agree on scenarios. PeteR: trying to make this document agnostic, move bootstrapping to the other document Spectrum profile encoding Current encoding has "channelized" view List of startHz, stopHz, power No power spec of "unavailable" ranges. Alternate encodings: piece-wise linear profile 1. list of (startHz, startPower, stopHz, stopPower) 2. ordered list of (frequencyHz, power) Ray: what's wrong with a channel list? BrianR: assumes there is only one power level for a given channel BrianR: second one should be ok Ray: ETSI model requires channelized power levels Wonder whether interpolation could be accomplished with finer grained start/stop channels We will take this issue to the list and discuss it further Open item: multiple rulesets May be different bands with different rules. Should we allow for that in the encoding? Room response is a collective shrug SubirDas: are we enforcing that everyone has to return multiple rulesets? BrianR: no, you can always return 1 Subir: if at a location, there are multiple rulesets, are you required to return multiple? Vince: it's up to the database. If it supports it, it should return the multiple. Subir: then device can choose whatever they want? Vince: device capabilities include bands it is able to operate in, database returns matching rulesets, device selects one it wants. Gabor: but at a location there is only one ruleset? Vince: no, can be multiple rulesets for a location. E.g., TVWS @3GHz, @5GHz No objection in the room to multiple rulesets. But, we need to take it to the list and confirm there Open item: Spectrum-use-notify, should it get a response? Some people envision using a response to this message as a yes/no whether spectrum is still available. May be complicating device logic, it should have just asked for that spectrum. BrianR: does this mean you don't have a reliable connection? Or is it TCP? Vince: has an HTTP response, just no body that should be interpreted by the device Ray: inconsistent with other specifications. BrianR: maybe response should be optional Ray: but in JSONRPC, something that is a notification is REQUIRED not to include a body in the response. Subir: currently there is a response, want to get rid of it? Gabor: message to the list that we should make it a pure notification PatSarvey, Ofcom: given that you will elicit a formal response, empty as currently stands, should acknowledge with an OK, and in the extreme event something has changed, you could give it a "stop" signal to say something has changed. Response could be meaningful. Ray: ofcom spec doesn't envision the notify being delayed from the AVAIL_SPECTRUM_RESPONSE. Can wait for 15 minute polling interval if something needs to change. BrianR: we are not chartered to deal with sharing among devices, need to be really careful about what this is for. Ray: was referring to interference with primary users, not between whitespace devices. Everyone in the room seems ok with this change. Open Item: JSON-REST encoding Features: uses HTTP headers to communicate versions, capabilities, cacheability. more naturally supports web browsers. Disadvantages: more tightly coupled to HTTP. Only a couple of people are aware of the discussion PeteM: would open the possibility that URLs may change over life of service BrianR: usually there would be just one URL, send requests there PeteM: but would open possibility, we don't want to go there PatSarkey(Ofcom): pondering non-repudiation, importance of certain messages. Should we allow this within the data structures? Vince: HTTPS guarantees that if you trust the database, the responses are signed by that database. From the device side, position has been that a rogue device can just operate using the spectrum without consulting a database, so adding infrastructure on that end may not be as valuable. BrianR: IFF you do mutual authentication (or authentication of the party from which you want non-repudiation) PeteM: can't do non-repudiation with HTTPs because you are supposed to throw away session keys RayB: so many ways to do JSON signing, would need to look at it very carefully to see why it's justified BrianR: it is a bit late to add new requirements Gabor to Pat: didn't you initiate discussion on the list? Pat: yeah, hinted at the interest today. Something to take away and think about. Outside of PAWS protocol itself, interested in providing another means of ensuring that listing server cannot be spoofed. DNSSEC would help. Can do some look-aside verification independently of TLS. Need to make sure infrastructure is not susceptible to hijacking. Gabor: need more discussion on the list PeteR: two things going on here. One is talking to the server you want to talk to, other is non-repudiation. Non-repudiation requirement is not clear. Pat: CAs can get compromised, DNSSEC is not a silver bullet, but we may need something for non-repudiation. DavidMandleberg: can you mandate one CA per regulatory domain? Pat: probably not, being a public body, there are competition issues. DNS is part of the infrastructure. PeteR: if you are willing to do DNSSEC, DANE can get you pretty much what you want. We will discuss some issues on the list, then you will make a new version of the draft, then we will do WGLC. Bootstrapping/Database Discovery ZhuLei Introduced last IETF, trying to solve open issues A number of issues that a possible solution can address Solutions could be: Pre-configured manually by owner of master WSD Configured by manufacturer Retrieved from Listing server Previous database redirect Some domains require listing service, may need to be discovered Separate discovery service may be more applicable Gabor: Solutn doc says master device needs to have database & listing server pre-configured. So things may work if you are at home, but you may not know where to go PeteM: need to know which regulatory domain you are in Gabor: just try until you don't get an error BrianR: if you have 100 preconfigured, don't want to run down the list DB discovery server: could be many all over the world, deployed without knowledge of each other. Could be hierarchical with a trusted root, but may want more distributed deployment. Requirements for WSDB DS R1: should have agreement with regulatory bodies R2: should maintain information for not only one regulatory body Gabor: are these requirements from the requirements document? ZhuLei: no, these are what we want it to do Gabor: concern about especially requirement 2 JuanCarlos: same concern as Gabor BrianR: whole point of a discovery service is to find the server or servers for a number of countries/regulatory domains. Fundamental idea is that there is a discovery service that tells you, based on your location, a list of databases that are available to you. PeteR: 6953 says: the master device identifies a database. The protocol MUST support the discovery given a location. MAY select by discovery at runtime, or may be preconfigured. JuanCarlos: not only one regulatory body is the concern. BrianR: if there is only one, you don't need discovery JC: one domain, several databases BrianR: listing service from UK is like that. PeteR: talk in terms of protocol. There is a WSDB protocol, talking to the database. Idea of a listing server is a referral service within the database protocol. After you've started talking to the database, it gives you a list. Idea of a discovery protocol is "tell me which database I need to connect". Alyssa: discovery service needs to be able to support multiple regulatory bodies, not that it has to maintain more than one. JC: maybe we can rephrase this, may maintain more than on but is not required. Vince: need to consider multiple band plans within the same regulatory domain, not just TVWS but other shared spectrum. BrianR: can imagine there's a database that covers TV bands, another that covers microwaves. Discovery thin might need some other way to do it. Need to handle that. DB Discovery mechanisms Simple call flow DISCOVERY_REQ, DISCOVERY_RESP RayBellis: Ofcom model for getting the databases, requirement is that they have to be able to de-accredit a database. Step 1 means DS is tightly bound to regulator. Need DS to return the URL of Ofcom's list. BrianR: sort of saying that. RayB: seems overly complicated. DS doesn't control which ones are accredited. PeteR: losing the thread a little. If I go to a database going to give me 1 or more PAWS URIs. You are saying device needs to know apriori that there are some things I want to talk to, some things I don't. Outside of this protocol. Then I don't understand your objection to step 1, the list returned then you do magic to pick one, what is the problem? RayB: So DS server doesn't know the preconfiguration Long discussion on trust issues in discovery process, whether the regulator needs to be involved in certifying WSDB. Who sets up the LoST server? Vendor/manufacturer of device. He had to go through the certification process with each regulator anyway. Vince: what if manufacturer ceases to operate? BrianR: then device breaks, if manufacturer hasn't used a third party RayB: would be useful for those who don't know LoST, some sort of primer that says given a seed URI for LoST, how that proceeds through one or more LoST servers. Could be access network provided, manufacturer provided, etc. BrianR: DHCP may not be good option (it was good for ECRIT). Gabor: can we conclude? BrianR: we are not in the position to adopt this as WG draft, but everyone seems to agree there is a requirement for a discovery service. Whether this draft is the basis, don't know, but it is helping us come up with the requirements/discussion. PeteR: recommend to the chairs: a lot of issues about LoST, what the requirements are. Hopefully can produce a summary of all these issues. A lot of open questions. Brian to make a summary of this discovery discussion on the list.