PAWS working group meeting - Orlando(IETF86) Tuesday, March 12th @ 1pm ========================================= Administrivia (5 min) Blue sheets, minute taker, jabber Note Well Agenda bashing Ofcom Status update http://www.ietf.org/id/draft-ietf-paws-protocol-03.txt, Vince Chen, 60min http://www.ietf.org/id/draft-wei-paws-database-discovery-00.txt, Zhu Lei, 20 min ========================================= Minute taker: Dorothy Stanley, Aruba Networks Chairs (Gabor Bajko, Brian Rosen) welcomed attendees. Chair reviewed the Note Well, including the IETF IPR Policy. Chair reviewed the agenda; one remote participant: – Cesar – will provide a status update on OFCOM. Have 2 documents to discuss today: protocol and database discovery. Chair reviewed the WG document status – Use case requirement document Does not include a requirement for a PUSH method to implement the Ofcom requirement. Can include in a charter revision in the future. Ofcom status update, Cesar In last 3 months, issued consultation on device requirements. Included legal requirements – technical requirements on devices. Closed in January Working on responses now. Working in ETSI to produce a harmonized standard. In ETSI-BRAN draft development, next step is public inquiry. Setting up future trial. Working on contracts with DB providers. Interested in question about PUSH requirement. In UK, PUSH requirement arises from regulatory requirements; can be implemented with PUSH or other mechanisms Interference management – shut down interfering device quickly; DB needs to reach devices quickly. Radio microphones in same bands – licensed, get assignments in same bands. Need DB to protect assignments. Need “kill switch” or “active update mechanism”. How soon is “soon” to shut down a device? Minutes? Hours? Probably hours. Just working it out now. To identify that a particular device is an interferer, need to shut down particular devices, see if interference resolved, if not, turn down other devices. Just started looking at this; enforcement team involved; may end up being unworkable. Don’t know yet. Ideally achieved in shortest possible time. At present, requirements support giving “time to live” on spectrum. Acceptable to give short allocations? If there was an hour timeout, would that be sufficient to address need, without changing the whole model. Once you decide you have a problem, can lower the time to live. Accommodate in current architecture – or is architecture change needed? Agnostic to how solution is architected or implemented. Exploring what the constraints are, determine if there are alternate ways to solve the problem. Initial reaction – require that DB can reach the device within 1 minute. Could comply with current mechanism, but don’t want all devices to come to DB every minute. Expand to 1 hour. Don’t currently support coming back regularly? Requirements include a Re-query time. Request – Cesar with other Ofcom folks to review the current use case document. Can changes still be made? Has one “Discuss” remaining; in IESG evaluation, believe issue is addressed; Doc editor will update doc, and then submit to RFC editor for publication. If need to change, very inconvenient – would have to update charter. Consider current document complete. Small enhancements can be made in the protocol document; large ones require revising the use case and requirements document. PAWS Protocol Document – Vince Chen Need to update the base draft document to indicate that it was the basis for this document. Status of the PAWS protocol document and review open issues; review extensibility and IANA registries. Protocol Overview described. Encoding: example Request reviewed. Encoding: example Response reviewed. There is expiration data for the channels that are being handed out. Encoding: example of GeoLocation reviewed. Extensibility characteristics described. IANA additions require expert review with specification required. Ruleset Identifier described. Represents a set of rules to be used within a regulatory domain. Description of Extensibility use. Review of ruleset identifier use cases, single and multiple ruleset support by devices. Device may indicate the rulesets it supports; not required in initial Request. Could have DB that supports multiple rulesets, determines ruleset to use based on location of device. What is scenario that wrong DB is contacted? If discovery is broken. Review of IANA PAWS Parameters Registry. Are Ofcom parameters well enough defined that the types can be added to the PAWS Parameters Registry? TBD. Review of IANA PAWS Error Code Registry. Review of IANA PAWS Ruleset ID Registry. Versioning is very important; naming also; regulatory space changes. Review Proposed IANA Process; update language description in text to reflect needs. Implementations – have reports of successful implementations. Question on location, error/uncertainty. Why are we using an ellipse rather than a circle? Because Ofcom defines uncertainty in 2 directions. Might be easier as a default with ellipse with equal axis. Does the schema have extension points? Yes. Suggest generalizing the regulator IDs. So that there is a formula. Even a regulator is not consistent – incent new IDs for reasons that don’t work for us. Potentially use regulator name, them variation under that; no, considered before. Concern with variations we saw – 2 countries that use same ruleset have to use different identifiers. Different from fccid (per device id) Since using the shapes from pidflo, are you considering using the privacy rules from pidflo? Privacy defined by the regulator. Regulator says what information is in Query and Response and what you are allowed to do with the data. FCC has some retention rules. Mandates or prohibitions? Mandates to hold for a specific time. Iis there a way to index into list by regulator? IANA registry is represented as XML. Find implementers confused with choice of names. IANA just a registry service; If it is useful to have a separate registry to point in – can add that; consider in design of the registry. Country, multiple regulators in the country. Polygon, list of points – is there a document that describes orientation? Yes, based on GML, make clear in Json Registry structure – was discussed last time; advocated flat registry structure. Country and regulators are not changing; if have a structure, might be able to do a better job. Country X adopts rules by FCC. Still, Country X will have a document. Want to discourage new names to be required. Why should we revisit this? Believe we closed at last meeting. Can re-open if there is new information. Perhaps need to summarize result; then consider if there are new use cases. Was summarized in the past. Chair: Are there any other open issues? None identified. Then revise the draft and go to WGLC. Database discovery part is still TBD; determine what to do with provisioning document, then update the TBDs. Could be assumed to be pre-provisioned. Hold that until we have the database discovery mechanism. Database Discovery – Zhu Lei Pre-configured manually by owner of WSD. Possible methods of retrieval of DB address for WSD Summary: Services LoST provides to DB discovery Brian Rosen: Summarizes how LoST works. Designed to be DNS-like tree of servers. Indicates area that information applies to. Also, link servers together. Do we want to define a discovery mechanism for TVWS DBs? Use LoST? Are we dependent on the access network? Need to discover the LoST server. Don’t want to be dependent on the access network. In some areas, there will be LoST servers for emergency servers, will be getting the info you want; piggyback on the servers that are already there. Can preconfigure; only works when you know ahead of time. Review od LoST server specification; LoST/HTTPS/TCP/IP Have to be able to send Lat/Long. May be use cases for civic. Review: Issues to be clarified PAWS uses JSON, LoST uses xml. Conveying of regulatory domain. What is the service list: DB addresses; get back list of UTLs. Worried about length of URL. There might be many URLs provided. What is the problem? Long list. Andy: OFCOM was planning to have a website that will have list of all websites of the DB providers. If vendor wanted to build a device that works in 5 countries; device needs to discover its location, then get DB info. Location Lat/Long provided – is region needed? Can the regulator have a website of DB info or does it have to be a LoST endpoint? If using LoST, have a mechanism to discover a UK LoST server, would return e.g 5 URLs to use to contact the available DB If info can be provisioned – easy. Authentication. How do I know that the server gives back the right info. Will have slave devices that don’t provide location. DB master info for master devices How are LoST ad WSDB deployed? Recursion and Iteration. Do we still need Paws protocol to support mutual authentication? Lost relies on U-NAPTR – difficult to get DNS admins to add new records to their zones. Have these issues been addressed in the draft? Most addressed, need to confirm, others not. Show of hands for who has read document? 6 or so. How do you get a DB listed? Up to regulator How do we know who is a regulator? Top level problem. LoST does not have an omnipotent route. Have trust between servers. Regulator has to figure it out. Return data – if have a list of DB, are there attributes per DB – e.g. cost? RFC 5222 can be extended to support more info. Chair: Want to get a sense of the room regarding discovery beyond provisioning. Also understand is LoST interesting as the basis of Discovery. Also, does this draft form the basis of what we want to use for discovery? Do we assume that there is no redired? There is none now. Can add. Provision an address, gets you to Server A; If Server A can’t serve you, send you to Server B. First question is the most important – do we need a discovery mechanism beyond provisioning? Others are arguing about how to do it. Is there a use case where simple provisioning is not adequate? Currently, discovery is in scope; assume that we will work on it. Would like to talk about discovery, but don’t want it to be a dependency on the protocol document. Believe that simple provisioning is good enough. Allow for a fixed URL; no objection to working on discovery. Q: Still interested in working on DB Discovery? If provisioning is enough, then answer is No. If want to go beyond, then “Yes”. Current PAWS doc allows HTTP redirect. Believe in short term, provisioning adequate. Long term – no. Assume provisioning is in the document. Humm: Continue to work on discovery: moderate hum. No: Low. Is there anyone who Needs Discovery straight away? If there are no clear guidelines, hard to say. Until see how discovery proceeds, can’t tell. In the future, anticipate needing discovery. Write the protocol document without a hard dependency on discovery. Any objection? None. Take results to list to confirm. Who believes using LoST is a good basis for discovery? LoST (with extensions)? Good to leverage IETF work. Not LoST – need to propose alternatives. Once concern is understanding the use cases and applying LoST to this business domain. If extend, then is result still LoST? Should we give LoSt a try? If can’t be fully extended, then need to go back and look at alternatives. Did anyone do an analysis that LoST is applicable to this domain? Don’t have an alternative proposal at this point. Issues are less around protocols than administration. Humm: Proceed on LoST consideration path: moderate Hum. No: None. Who at this time would like to make this document the basis of LoST? Humm: Moderate: Opposed: Moderate. Take to list. Meeting adjourned 1500 local time.